Web interface Live TV roll over issue

[snagglewest]

Sub,

Updated to V5.0.0.190916 last night on my test machine and I've run into a issue. The live TV is not working correctly from the web interface. When a stream is started everything seems to go fine until about 4-5 min or so when the feed freezes. clicking the pause and then play gets things moving again but it starts over from whenever the stream was initially started. I've tested this from an android device and a Linux (chrome) browser. Both do the same thing. Kodi does not seem to be effected.

The files are created in the livetv directory, for example, the last test I ran from chrome in Linux created live-WAVY-HD-1229-6.ts & live-WAVY-HD-1229-6.ts.map and then continued creating subsequent files starting with -1 thru -3 with each being 85-100kb. At that point it froze and I had to hit pause/play to get it streaming but as before, it restarted the stream from when the session was initially started. It repeats the same process over and over each time going back to the initial stream start point. The attached logs show it doing this 3 times in a row.

[ATTACH=CONFIG]47590[/ATTACH]

[snagglewest]

Had some more time to test some more in this which stated after the update to V5.0.0.190916. I'm running behind a Apache proxy server and I've tested it both through the proxy and directly by IP within the LAN. Both Windows & Linux and both act the same.

Chrome -
stream auto starts viewing after buffer fill
Stops streaming after appox 4 min with 4 .ts buffer files. Seems to be when the 5th file should be created is the point it chocks.
Clicking pause/play started the stream again from the point it was initially started.
After ending stream it deletes all the .ts files but leaves a large .nfsxxxxxx file which appears to be a all 4 .ts files in one. It's playable in VLC and seems to be what's actually playing after clicking play/pause.

Firefox -
stream does not auto start after buffer fill, need to click pause/play to start viewing
after ending stream deletes all .ts files, does NOT leave a .nfsxxxxxx file

Any ideas?

[BrettB]

Had some more time to test some more in this which stated after the update to V5.0.0.190916. I'm running behind a Apache proxy server and I've tested it both through the proxy and directly by IP within the LAN. Both Windows & Linux and both act the same.

Chrome -
stream auto starts viewing after buffer fill
Stops streaming after appox 4 min with 4 .ts buffer files. Seems to be when the 5th file should be created is the point it chocks.
Clicking pause/play started the stream again from the point it was initially started.
After ending stream it deletes all the .ts files but leaves a large .nfsxxxxxx file which appears to be a all 4 .ts files in one. It's playable in VLC and seems to be what's actually playing after clicking play/pause.

Firefox -
stream does not auto start after buffer fill, need to click pause/play to start viewing
after ending stream deletes all .ts files, does NOT leave a .nfsxxxxxx file

Any ideas?

Keep in mind that the web interface is not intended to be used for normal, daily usage--especially for playing recordings or live tv. Those will always have to be transcoded to play in a web browser which puts significant load on the server. And each different combination of operating system and web browser introduces differences in behavior as you've already found.

If your server is up and running OK, then you'd be better off focusing on getting a true client (the Windows client, one of the nLite clients, Kodi via the add-on or via knewc, the Android client, the iOS client, etc.) working.

[snagglewest]

The server is well up to the task loafing along in the 10-15% cpu usage range even when transcoding. The point is, this problem was introduced with the most recent update. On the last V5 version it was working flawlessly as has V4 and it's predecessors for at least the last 8 years.

[BrettB]

The server is well up to the task loafing along in the 10-15% cpu usage range even when transcoding. The point is, this problem was introduced with the most recent update. On the last V5 version it was working flawlessly as has V4 and it's predecessors for at least the last 8 years.

In that case, then it is most useful if you post the server logs and indicate the time that you did various tests so that they can be matched up to the log files.

[sub]

Can you restart your NextPVRServer.exe (to reset the logs), reproduce the issue just one time (with no other clients doing stuff), post the logs and let me know the time it happened. Also post the *.log file from the web/temp directory (the ffmpeg transcode log)

[snagglewest]

Sub,

Here's clean logs for both Npvr and ffmpg. The test was from a Chrome browser and I started Npvr, ran the test which crapped out and then I stopped Npvr to pull the logs so they should only show the one event.

While poking around I did find something else interesting though. Not sure if it's related but the /var/opt/nextpvr/web/temp directory had over 4,000 small .ts artifact files with names like "WTKR-HD-f440676589d349a6a6b8e4230ce79eed7.ts". The files were 2sec long or so on average and some as old as Sept 10th. Not sure exactly why their being left, but definitely filling up the HD when running in a VM with a fairly small virtual drive.

As far as the livetv buffer directory, once the stream crapped out it deleted all the .ts files but then left a 100 mb file named .nfs0000000000011d1a0000001e. The file is playable in VLC and is a combination of all 4 .ts buffer files. If it would be useful I can put it up on a dropbox.


[ATTACH=CONFIG]47635[/ATTACH]

[snagglewest]

Since others have mentioned similar problems in other threads, I thought I'd mention this...

After a bit more investigation and a building a completely new Ubuntu 18.4LTS VM with Version: 5.0.0.191007, I haven't found the problem exactly, but I did find a workable solution.  I probably didn't make it clear earlier that I had moved the recording and live TV buffer directories to a NFS share on the server.  This works fine for recordings, but for whatever reason, which I've never really figured out, live TV was crapping out after the 4th buffer file was written.  As a result a large .NFSxxx file was being left when the file was improperly closed.

I'm not sure why this happens on a NFS shares and only with live TV, but moving the livetv buffer directory back into the VM solved the .NFS file and the live TV problems.

[mvallevand]

The NFS file is likely left over when NextPVR deletes a file that is not closed. This is allowed in Linux but not Windows. It probably is the first rolling file

Martin