M3U IPTV Closing Connections Automatically

Channels DVR Server
#13

I went back to tivimate and tried multiview on my shield. No issues whatsoever opening up 5 connections and playing them all. A couple slight buffering issues depending on the channel bring loaded but it always reconnected.

Only difference is that I’m not using m3u4u to reduce the channels and add some correct epgs.

image
image1920×1440 184 KB

I can try using the direct m3u link instead of the m3u4u one and see if that makes any difference.

If this doesn’t work, then I’d try a completely different m3u source altogether to see if that makes any difference.

if that doesn’t work, there must be something going on with the actual Channels DVR server not reconnecting/timing out to some of the feeds.

One thing I'll add is that I realize this is all a work in progress and I really appreciate the work you guys have put into this and don't want anyone to think I'm ungrateful - quite the contrary. I realize it's not easy. I'm thankful that you even implemented this as an option. I'm hoping that if it's an issue on my end, that maybe if it can be solved it can help other people.

2 Likes
#14

I'm a little confused. So are you asking:

  1. disconnect the NAS as storage and test only the epg/m3u source on the pc?
  2. Stop the windows channels dvr server and install a docker version on windows and give that a test (while keeping the NAS still disconnected from channels dvr server?)

Would be great if the cache could be local on my PC while I use the NAS as only DVR storage. Let me know if that's how this works or if I need to do something differently with setup. The PC's main nVME is limited in size.

#15

No.
What I meant was to add a second Channels DVR server instance running in a docker container using only your IPTV for source, and using the WIN 11 PC for the recording directory just to test.
Doing a recording will generate more info in the dvr log.

1 Like
#16

Thank you for explaining that. Will try this later and write back in with the results.

#17

You can submit diagnostics after the issue occurs. We will take a look to see if there is an obvious issue on our side, but in general we do not provide support for iptv providers.

1 Like
#18

I totally get that and appreciate your response. I'm trying to isolate if it's something on my end or with the software. As soon as I'm don't with my current work I'm going to install the system on my other work PC which has similar specs without all the other connections (nas, xfinity, etc.) and see if the issue persists.

#19

Update SUCCESS (so far): I disabled the server I had issues with and installed a fresh copy of CDVR on a similar computer. I made sure to keep it to a bare minimum and this time didn't use the NAS as primary storage similar to what @chDVRuser suggested. I was able to actually watch ST TNG for a good 45 minutes without any issues off of my Shield which was a first.

So, I'm now thinking my issue was a connection between the NAS and that initial server, possibly a protocol or even faulty networking cable. I just moved my NAS and Server onto new CAT 8 cables and reconnected everything. I also dropped QNAP NAS SMB versions from 3 Max to 2 Minimum (I'm not sure if SMB has any impact tbh but I used to have it enabled on my old unit.) Testing the server again with the new cables and so far it's running smoothly. I'm going to let it run for a while and hopefully it doesn't cut out.

I'd feel really stupid for wasting everyone's time if it all came down to a simple ethernet cable issue but that's much better than the alternative which is a 32TB NAS which is problematic and can't be used for reliable storage. Will report back. I had assumed there would have been some sort of built-in buffering or reloading for spotty connections.

#20

Update success #2: I did eventually have a signal cut out on me with the new cables to the NAS, but it lasted a lot longer than previous attempts.

So I decided to relocate everything over to a local drive on the server. It’s not a lot of space but I have extra failover drives including externals. I’d still like to eventually use the NAS as storage but I feel the cache should at least be localized if the devs can implement this.

Ever since having everything local, the IPTV channels are coming in fine. In fact, so far I’m seeing far less hiccups and buffering on this setup than I do with my Tivimate on my shield pro which I wasn’t at all expecting to see. I thought the previous hiccups on tivimate for the past few months was mostly due to iptv server lag but I may have been wrong all along.

Anyways will continue to monitor it. I’m disappointed that my NAS even on a 2.5gb connection acts intermittently. Not sure if this has anything to do with flow rate, maybe I’d need to specify a wins address, etc. I’m open to networking suggestions/practices.

1 Like
#21

Similarly, I just got Channels set up yesterday with an IPTV service as well. I manually edited the m3u to keep the channels I want, and spoofed the channel numbers to match my local provider.

I don't know if it is the IPTV service or not, but I am also experiencing random disconnects whether watching live TV or recording content:

2022/06/29 12:01:37.385574 [TNR] Opened connection to M3U-IPTVTest for ch621 National Geographic
2022/06/29 12:01:37.385740 [DVR] Recording for job 1656518400-ch621 from M3U-IPTVTest ch621 into "TV/Drugs, Inc. The Fix/Drugs, Inc. The Fix S02E17 2019-07-24 Cannabis Craze 2022-06-29-1201.mpg" for 1h1m23.116906718s
2022/06/29 12:01:37.468434 [IDX] Generating video index for job 1656518400-ch621
2022/06/29 12:06:02.016089 [TNR] Closed connection to M3U-IPTVTest for ch621 National Geographic
2022/06/29 12:06:02.016125 [DVR] Job 1656518400-ch621 Drugs, Inc.: The Fix ended prematurely: 56m57.983880591s
2022/06/29 12:06:02.048212 [DVR] Starting job 1656518400-ch621 Drugs, Inc.: The Fix on ch=[621]
2022/06/29 12:06:02.347069 [TNR] Opened connection to M3U-IPTVTest for ch621 National Geographic
2022/06/29 12:06:02.347160 [DVR] Recording for job 1656518400-ch621 from M3U-IPTVTest ch621 into "TV/Drugs, Inc. The Fix/Drugs, Inc. The Fix S02E17 2019-07-24 Cannabis Craze 2022-06-29-1201.mpg" for 56m57.951689986s
2022/06/29 12:11:03.268069 [TNR] Closed connection to M3U-IPTVTest for ch621 National Geographic
2022/06/29 12:11:03.268116 [DVR] Job 1656518400-ch621 Drugs, Inc.: The Fix ended prematurely: 51m56.731890411s
2022/06/29 12:11:03.271934 [DVR] Starting job 1656518400-ch621 Drugs, Inc.: The Fix on ch=[621]
2022/06/29 12:11:04.009196 [TNR] Opened connection to M3U-IPTVTest for ch621 National Geographic
2022/06/29 12:11:04.009302 [DVR] Recording for job 1656518400-ch621 from M3U-IPTVTest ch621 into "TV/Drugs, Inc. The Fix/Drugs, Inc. The Fix S02E17 2019-07-24 Cannabis Craze 2022-06-29-1201.mpg" for 51m56.727981997s
2022/06/29 12:14:02.663703 [TNR] Closed connection to M3U-IPTVTest for ch621 National Geographic
2022/06/29 12:14:02.663763 [DVR] Job 1656518400-ch621 Drugs, Inc.: The Fix ended prematurely: 48m57.336244273s
2022/06/29 12:14:02.684200 [DVR] Starting job 1656518400-ch621 Drugs, Inc.: The Fix on ch=[621]
2022/06/29 12:14:02.897737 [TNR] Opened connection to M3U-IPTVTest for ch621 National Geographic
2022/06/29 12:14:02.897812 [DVR] Recording for job 1656518400-ch621 from M3U-IPTVTest ch621 into "TV/Drugs, Inc. The Fix/Drugs, Inc. The Fix S02E17 2019-07-24 Cannabis Craze 2022-06-29-1201.mpg" for 48m57.31570916s
2022/06/29 12:14:03.089045 [TNR] Closed connection to M3U-IPTVTest for ch710 MTV

2 Likes
#22

You have tivimate? I’d give that a try and use multi view to see if you can see concurrent streams. If it doesn’t, then you’re probably limited to 1 stream at a time and if a recording is happening on another stream it might be kicking you out.

Or perhaps if you have a provider they might actually say how many concurrent connections you’re allowed.

Then, my second question would be: is everything local or over a network? Making everything local seems to have resolved most of my issues.

#23

I'm on a 24 hour trial with a provider right now. I do have multiple streams, so I can rule that out. Everything is over my local network as well. I have gig fiber coming in, and everything is hardwired. Very annoying issue.

I had tried TV Everywhere with my ISP, which worked perfectly. However, I was disappointed that not all the channels I pay for have a TV Everywhere channel. Sounds like other providers have different TV Everywhere channels, but never all the ones I want. There is too much fragmentation in this stuff, I thought it would be a lot easier to cut the cord at this point.

#24

Local as only on your server and not a network share?

Much of my iptv issues resolved when I tried to only run it off my main server/comp unfortunately.
It sucks because I have 36tb of NAS space available and the iptv connection isn’t reliable when I’m hooked into it.

1 Like
#25

Correct, not on a network share. I have a PC running Linux on my LAN that I use to run a Plex Media Server. Saw the potential with Channels DVR running on that and ventured down this rabbit hole.

1 Like
#26

You have any non-iptv sources and are they stable?

I’d almost try the GitHub iptv collection and see if it’s simply your trial.
There was also one Canadian guy who was providing free and legal iptv lists. Really nice person. I’ll try to find the link for you.

Also, what are you using to condense your list? Everything seems to be working fine with m3u4u.

Update: went looking for the guy who had legal sources (pulled from channel website sources) but can't seem to find him now. It's been a while. Sorry can't help you out but I'd definitely test some of those github sources first.

#27

I don't know what it is at this point, but I'm hoping it's just the IPTV provider. Maybe another one will fix it.

As far as condensing the channels list, I opened the .m3U in notepad, did a search for the channels I wanted (about 50 of them), and copied them over one by one into a new text document. Each channel starts with "#EXTINF:-1" and ends with the URL to that stream. I also added tvh-chnum="channel number here" to spoof each channel number and cleaned up the tvg-name and group-title to match my local cable provider. Worked perfectly for pulling in guide data through Channels DVR.

3 Likes
#28

Maybe I spoke too soon because I’m getting drops suddenly again. Maybe coincides during busier times of day with signal stuttering. I’m beginning to think Tivimate is able to pick up the streams after interruptions whereas Channels just cuts the connection altogether,

Might have to explore different, more stable sources.

1 Like
#29

Run your m34u through an xteve server. Set xteve to use ffmpeg as a stream buffer. Then have Channels pull the m3u/xml from the xteve server.

#30

Ack. I hated setting up xTeve as a workaround for Plex. Having to redo the guides constantly did my head in. Not sure if there’s anything really gained buffer-wise.

UPDATE #3: I tried a different source as a test that uses HLS instead of MPEG and definitely allows for 4 concurrent connections. My previous list said it only allowed for one but I was able to stream multiple (not sure that makes any difference.) It’s been the best performing so far. There’s occasional hiccups from the provider but extremely brief and it always reconnects.

So I’m leaning away from the actual networking and localized dvr setup, and thinking it might be either:

  1. Iptv source stability (channels cutting out as a result.)
  2. Iptv source concurrent connections (more is better.l
  3. Perhaps it has more to do with IPTV stream typeS: HLS vs. MPEG. Having better luck so far with HLS.
#31

HLS is meant for internet streaming, so it will be more reliable.

I'm going to close this thread now, because as stated earlier we do not provide support for IPTV usage.

The takeaway here is that our software works great when you have a reliable local source for video, such as a tuner which exposes M3U.

When you get into this world of shady IPTV resellers, you're receiving a signal that's from an unknown and unspecified source, likely bouncing between dozens of servers all introducing their own latency. It's great if other software is able to better handle such streams- use that software. Our position is that garbage in = garbage out, and we not interested in optimizing our software for this use case.

3 Likes
#32