NPVR stops playing live TV at about 6 mins

[Tnix]

Hi all,

I'm using the latest NPVR backend release on Linux with a RTL DVB-T tuner with Kodi NPVR add-on. When I tune to watch a live TV channel it's well played until it freezes at about 6 minutes and stops returning to Kodi's channel list.
I've sured that in the same time there's no EPG searching.
I've attached both "device-adapter0.log" and "nrecord.log" (in NPVR_logs.zip) to this post. I've tested in the time period between 19:53:17 and 20:00:26.

Any help will be appreciated. Thanks in advance.

Regards.

[mvallevand]

Next time don't manually copy the logs, you miss cached info, use the download logs option on the settings page.

How much memory is on you PC or VM/container.

2024-04-01 19:49:36:853 [ERROR] Unable to get shared memory!

Martin

[Tnix]

Next time don't manually copy the logs, you miss cached info,  use the download logs option on the settings page.

How much memory is on you PC or VM/container.

2024-04-01 19:49:36:853 [ERROR] Unable to get shared memory!

Martin

Sorry. I've attached the downloaded logs.

My machine has 8 GB RAM.

Thanks.

[mvallevand]

Sub's going need to look to see why that memory is not available when the rolling file rolls. That tuner you are using is definitely not a quality product but that is likely not the source of the problem (unless it is eating memory, you might want to monitor that.

We also don't have any experience here using buildroot or batocera here and it is not a supported plaform for netcore so there could be other things at play. DeviceHostLinux that is failing isn't netcore though.

You probably can avoid the problem by increasing the rolling file size to a very large number 180 minute (*60) will give you an hour before the roll that cause the memory error.

Martin

[Tnix]

Sub's going need to look to see why that memory is not available when the rolling file rolls.  That tuner you are using is definitely not a quality product but that is likely not the source of the problem (unless it is eating memory, you might want to monitor that.

We also don't have any experience here using buildroot or batocera here and it is not a supported plaform for netcore so there could be other things at play.  DeviceHostLinux that is failing isn't netcore though.

You probably can avoid the problem by increasing the rolling file size to a very large number 180 minute (*60)  will give you an hour before the roll that cause the memory error.

Martin

Thanks. I'll investigate more about the increasing rolling file size.

Regards.

[sub]

If you try watch in the web app, does it let you watch past 6 minutes?

[mvallevand]

Wouldn't DeviceHostLinux work the same way when it rolls? His always fails on the memory error.

Code:

024-04-01 20:00:24:694 [DEBUG] Boing (sid=193)
2024-04-01 20:00:24:694 [DEBUG] on request adapter0, frontend0
2024-04-01 20:00:24:695 [INFO] Tuning: 530000000 Hz
2024-04-01 20:00:24:695 [DEBUG] already tuned to the correct frequency
2024-04-01 20:00:24:695 [DEBUG] **********before Writer::Create()
2024-04-01 20:00:24:695 [INFO] Creating writer for: LIVE&/recordings/live-Boing-2237-5.ts (live mode)
2024-04-01 20:00:24:695 [DEBUG] mutex would be: Global\NPVR-mutex-84103dfa326722310ee31d2b7286c0a4
2024-04-01 20:00:24:695 [ERROR] Unable to get shared memory!

Martin

[sub]

Yes, but this isn't just a file roll - it's retuning and everything.

I think the problem has actually happened right at the beginning of the stream. Possibly something like either/both of deivcehost or nrecord doesn't have the permissions to get shared mutex or memory mapped file.

[mvallevand]

Gotcha, it this range request from Kodi causing the reopen I guess rather then reading the rolling file.

Code:

2024-04-01 19:49:36.814    [DEBUG][46]    Got request [127.0.0.1]: /live
2024-04-01 19:49:36.814    [DEBUG][46]    /live?channeloid=7183&client=XBMC-abf2275b24ba41429a5598f4f44b0736
2024-04-01 19:49:36.814    [DEBUG][46]     - channeloid: 7183
2024-04-01 19:49:36.814    [DEBUG][46]     - client: XBMC-abf2275b24ba41429a5598f4f44b0736
2024-04-01 19:49:36.814    [DEBUG][46]    range: bytes=229113856-
2024-04-01 19:49:36.814    [DEBUG][46]    Checking XBMC sid: abf2275b24ba41429a5598f4f44b0736
2024-04-01 19:49:36.814    [DEBUG][46]    StreamNative@1..
2024-04-01 19:49:36.814    [DEBUG][46]    StreamNative@2
2024-04-01 19:49:36.814    [DEBUG][46]    StreamNative@3
2024-04-01 19:49:36.814    [DEBUG][46]    StreamNative@4
2024-04-01 19:49:36.814    [DEBUG][46]    StreamNative@5
2024-04-01 19:49:36.815    [DEBUG][46]    StreamNative@6
2024-04-01 19:49:36.815    [DEBUG][46]    StreamNative@7...
2024-04-01 19:49:36.815    [DEBUG][46]    StreamNative@previous-handle = 1376257
2024-04-01 19:49:36.815    [DEBUG][46]    StreamNative@8 (/recordings/live-Boing-2237-3.ts)
2024-04-01 19:49:36.815    [DEBUG][46]    about to start stream...
2024-04-01 19:49:36.815    [DEBUG][46]    StartStream(7183:Boing)
2024-04-01 19:49:36.815    [DEBUG][46]    checking if previous capture source can be reused
2024-04-01 19:49:36.815    [DEBUG][46]    checking if previous capture source can be reused
2024-04-01 19:49:36.815    [DEBUG][46]    http://localhost:43627/stream/start?slipseconds=1200&target=LIVE%26%2Frecordings%2Flive-Boing-2237-3.ts

[Tnix]

Hi again,

I've noted that in NPVR web settings were specified both "Live TV Buffer Directory" and "Recording Directory" as "/recordings" (default value). Maybe due to specific characteristics of Buildroot (overlays, ...) these folders are "mapped" to p.e. "/share/system/wine-bottles/model2/dosdevices/ZSXKM0~L/proc/15136/root/recordings/" (there are many more corresponding to several PID). And maybe too this "virtual space" could be limited and for these reason the recording buffers could be exhausted.

Now I've set "Live TV Buffer Directory" and "Recording Directory" to another local folder like "/userdata/system/recordings/". In fact this folder was already there but it was strange I didn't see any data into when I run NPVR. Now it works fine: I can see data buffered into .ts files and the time played is OK.

Everything thanks to your help and clues Thank you very much. Nevertheless I'm testing in depth next days.

Regards.