Tvheadend

Michael Freeman wrote:

James Beuzeval wrote:

I was having a problem when recording with the recording stopping when it reached a size of 2GB. I was recording to a network windows share (mounted by cifs or nfs) and i'd get a "message write failed - file too large" when it reached 2148mb which would be around 30 minutes for a HD recording. This didn't make sense as it was writing NTFS.

Anyway, I isolated the problem which was due to the SMB version. I had to explicitly set it to v1 in my cifs mounting script and in my OS (LibreELEC).

This was the thread which eventually helped me - https://forum.libreelec.tv/thread/12531-smb-copy-of-file-2gb-fails/

Not sure if my problem was specific to LibreELEC but thought I'd post here as it may help somebody.

This is not exactly my situation, but gives me something to test. I will check it out and get back to you. Thanks!

Nope, didn't apply to my situation. That's because I wasn't writing to a SMB share (been awhile since I've looked at this). But thanks anyway.

Michael, from the log you posted it seems like you are recording from an IPTV provider, using multicast traffic.

I'm wondering what happens if you just tune to the same channel for over two hours (without changing channels - you may need to tweak your Kodi to not switch off the stream due to idling rules).
I suspect the stream will also be cut after two hours. This may either be your IPTV provider setting an upper limit on tuning time or the intermediate network setting a limit. For example, if you use IGMP snooping on your switches the implementation of that may be flawed and cut the stream off because it decided you are not connected anymore to the stream.

So if the stream is cut after two hours when normally watching, you should look for the problem in the network and/or your IPTV provider (although it is still possible it is a TVHeadend bug). If staying tuned does work then it likely is a TVHeadend bug.

Jeroen Bogers wrote:

Michael, from the log you posted it seems like you are recording from an IPTV provider, using multicast traffic.

I'm wondering what happens if you just tune to the same channel for over two hours (without changing channels - you may need to tweak your Kodi to not switch off the stream due to idling rules).
I suspect the stream will also be cut after two hours. This may either be your IPTV provider setting an upper limit on tuning time or the intermediate network setting a limit. For example, if you use IGMP snooping on your switches the implementation of that may be flawed and cut the stream off because it decided you are not connected anymore to the stream.

So if the stream is cut after two hours when normally watching, you should look for the problem in the network and/or your IPTV provider (although it is still possible it is a TVHeadend bug). If staying tuned does work then it likely is a TVHeadend bug.

Hi Jeroen, I'm using a HDHomerun Prime cable tuner connected to a Verizon Fios network. TVH sees it as an IPTV network.

During my initial troubleshooting attempts, I tried to isolate and eliminate as many variables as possible. The cable card is new. The tuner is used, but works just fine when connected to NextPVR running in a Windows 7 host - no time limits whatsoever. I made sure I was using the most recent HDHomerun drivers and firmware. I tested it with TVH versions 4.2.3 - 4.2.8. I switched back and forth between OSMC, Ubuntu, and Synology implementations and got the same answer - whenever I tried to record anything longer than 2 hours, I would lose the input stream. TVH thought it was still recording, but the stream had terminated. And in all cases, NextPVR never complained - using the same network, stream provider, and tuner. In my mind, that eliminated the possibility of network problems.

And you're right, it's not the recording function. Whenever I tried to watch the same channel for more than 2 hours, it would drop the signal.

So after limited response from the forum, I threw in the towel, and whenever I needed to record something longer than 2 hours, I would use NextPVR. But I'm in the process of upgrading my box (cpu, mb, etc) and want to use Ubuntu as my primary OS and eliminate Windows as much as possible. I would definitely like to get to the bottom of this. But I'm not very Linux or network savvy, so if you have any other ideas that could help me solve this problem, I would greatly appreciate it.

Thanks!

Kodi client on OpenElec + TVH 4.2.8 on Ubuntu 18.04 + HDHomeRun prime

I’ve been having the same issues with 2 hour recording limits. After months of research and fiddling, I believe I have my bug resolved.

Symptoms:
- Scheduled recordings stop at 2 hours
- Streaming stops at 2 hours
- When recording a show in progress, the recording appears to stop at different lengths.

Troubleshooting:
- Was able to determine that all streams and/or recordings stop at two hours. It didn’t matter when I started or the picture resolution of the stream, it always would simply stop streaming. Did not matter if the stream was on a remote client or VLC on the server machine.
- Looked at network settings in client, server and HDHomeRun. Updated all. No change.
- Attempted FTP KeepAlive script. No change

After a lot of snooping around, I found that during the original build, I had erroneously left a line in the Playlist.m3u building script. When I looked in each mux, I found each URL ended with:

“?Duration=7200”.

7200 seconds = 2 hours
Doh!

The tutorial that I used for the m3u building script was an awesome time saver. Simply customize the script a little and run it. Takes no time to generate a m3u file. The tutorial does mention that the “duration” is required by some apps. However, it seems it should not be used for TVH. If I’d just researched a little further, I’d have saved myself lots of time.

Resolution:
- Rewrote the m3u building script to exclude the “duration.”
- Edited each mux to eliminate the ‘duration.’ For some reason, when I scanned the revised Playlist.m3u, the ‘?Duration=7200’ remained. However, after editing the muxes themselves and rescanning, the URL was correct.
- Rescanned muxes
- Remapped services

Note: I did not want to rebuild the channel altogether. I have lots of time in editing and didn’t want to have to do that all over again. Someone here might have a quicker easier way.
Also, I cloned my HDD prior to fiddling too much. Just a precaution.

48 hours after the modifications, all appears to be running smoothly.

Hope this helps someone who may have made the same mistake I did.

Pike Kevin wrote:

Kodi client on OpenElec + TVH 4.2.8 on Ubuntu 18.04 + HDHomeRun prime

I’ve been having the same issues with 2 hour recording limits. After months of research and fiddling, I believe I have my bug resolved.

Symptoms:
- Scheduled recordings stop at 2 hours
- Streaming stops at 2 hours
- When recording a show in progress, the recording appears to stop at different lengths.

Troubleshooting:
- Was able to determine that all streams and/or recordings stop at two hours. It didn’t matter when I started or the picture resolution of the stream, it always would simply stop streaming. Did not matter if the stream was on a remote client or VLC on the server machine.
- Looked at network settings in client, server and HDHomeRun. Updated all. No change.
- Attempted FTP KeepAlive script. No change

After a lot of snooping around, I found that during the original build, I had erroneously left a line in the Playlist.m3u building script. When I looked in each mux, I found each URL ended with:

“?Duration=7200”.

7200 seconds = 2 hours
Doh!

The tutorial that I used for the m3u building script was an awesome time saver. Simply customize the script a little and run it. Takes no time to generate a m3u file. The tutorial does mention that the “duration” is required by some apps. However, it seems it should not be used for TVH. If I’d just researched a little further, I’d have saved myself lots of time.

Resolution:
- Rewrote the m3u building script to exclude the “duration.”
- Edited each mux to eliminate the ‘duration.’ For some reason, when I scanned the revised Playlist.m3u, the ‘?Duration=7200’ remained. However, after editing the muxes themselves and rescanning, the URL was correct.
- Rescanned muxes
- Remapped services

Note: I did not want to rebuild the channel altogether. I have lots of time in editing and didn’t want to have to do that all over again. Someone here might have a quicker easier way.
Also, I cloned my HDD prior to fiddling too much. Just a precaution.

48 hours after the modifications, all appears to be running smoothly.

Hope this helps someone who may have made the same mistake I did.

Now that is BIG! And the 1st explanation that makes sense. I've been muddling through with my workaround, but still unsatisfied that there seemed to be no "clean" solution. I guess that's what happens when you are retired, have too much free time on your hands, and have an engineering background. :-)

At any rate, thanks for that, I'll try it out today on one of my test platforms and let you know how it goes.

Doh! I looked at my config, all have the time limit of 7200!. I added every mux that my hdhomerun found
[784!] partly on principal and partly because I dont know how many of those I may randomly use.
[Probably a dozen or so, if that].
So now I'm stuck with changing all mux entries either using the web-gui [tedious] or
with a script. But come to find they are not readily editable as they are zlib encoded.
So the script would have to "export" the entry, change it and import it again.
There's a whole other "discussion" on that topic.

I wasted a lot of time getting all this setup with hours of manual editing originally
that I dont want to blow away. Although if (hdhomerun)"cablecard" support appears in the 4.2
stream I may do just that. I did my own build using a patch and using a shell script
was able to populate all the muxes automatically using the hdhomerun lineup.

I can confirm that the "duration" argument was definitely the problem. I was able to edit the muxes, rescan the network, and record for more than 2 hours with no problems.

That's not to say that I didn't encounter any problems. I am running my setup on a Synology NAS, and was in the middle of upgrading from one version of the OS (4.3) to another (5.2) and migrating my TVHeadend configuration and recordings from one (physical) box to the other. Nothing like having a little fun by adding variables to the scenario, right?

So I did a lot of testing in my VM environment before actually implementing the mods on my physical box. I eventually got it all working but it was an adventure requiring me to learn some things about the way TVHeadend works internally.

And now that I've got it all working, I'm having stability problems with my network tuner (Silicon Dust HDHomerun Prime). For some reason, it keeps losing power and shutting down. Oh well, that's a different problem for another day.

It's all good.

I have the same issue. I've read the thread and from my understanding, it's fixed by deleting the Mux, scanning for the Mux again and... recreating all your channels. I've done this, but it still stops at 2 hours?

Any tips for fixing it? I'm using docker and linuxserver/tvheadend on Build: 4.3-1789~g6bfeca6c0.

(This NBA is on tomorrow and it the stream keeps cutting out D

bob winters wrote:

I have the same issue. I've read the thread and from my understanding, it's fixed by deleting the Mux, scanning for the Mux again and... recreating all your channels. I've done this, but it still stops at 2 hours?

Any tips for fixing it? I'm using docker and linuxserver/tvheadend on Build: 4.3-1789~g6bfeca6c0.

(This NBA is on tomorrow and it the stream keeps cutting out D

Did your muxes have a "duration=7200" parameter at the end of each line? If so, you have to edit each line and delete that parameter, then rescan the muxes and rebuild your channels. That's what finally worked for me. Hope this helps.