Playback of recorded TV hangs on seek step backward


I’m running the Februrary release of OSMC on a Raspberry Pi 3. The Pi is connected to a Windows 10 desktop backend running running NextPVR. NextPVR is enabled on the Pi. I have the OSMC wifi dongle installed and connected to my router/gateway at 5G. I’ve installed and run iperf and the connection speed to my backend is between 60 and 90 megabits per second. I use a flirc USB dongle for remote control.

I’ve noticed that, when watching recorded TV, if I press back arrow or comma (via the flirc dongle programmed to my remote) to seek step backward, playback of the recorded program often, but not always, hangs with a “buffering” message. Playback doesn’t hang when I press forward arrow or period to seek step forward. When playback hangs, if I press X (stop) I can select the same program again and resume playback where I left off.

For reference, I also have a Windows 7 laptop running Kodi and I don’t experience the hanging phenomenon with it. It is also connected to the backend at 5G, and a run of iperf produces similar connection speed.

I’ve generated full logs on the Pi while replicating this problem. Logs are here:

Any idea what might be causing this problem and how I might fix it?


You are underclocking your Pi3:


Those numbers should be 1200 and 400.

You also have serious connectivity issues to your NextPVR server. 60-90 Mbits/sec is rather slow and it looks like you might be getting drops in the connection. (You’re using an OSMC dongle, aren’t you?)

02:00:09.893 T:1664922368   ERROR: CCurlFile::FillBuffer - Failed: Couldn't connect to server(7)
02:00:09.893 T:1664922368   ERROR: CCurlFile::Open failed with code 0 for
02:00:09.893 T:1664922368   ERROR: Open - failed to open source <>
02:00:09.893 T:1664922368  NOTICE: AddOnLog: NextPVR PVR Client: Disabling recording update.  Update NextPVR to v3.4

Similar messages are repeated many times.

As far as caching is concerned, Kodi will have a read-ahead cache but keeps very little for skipping backwards.

He likely doesn’t need to change any numbers, just revert to normal preset in MyOSMC.

Thanks very much for the quick responses!

Interesting. I checked the overclock settings and noticed that my Pi had “Custom” overclocking set, with the following settings:

arm_freq 850
sdram_freq 450
core_freq 375
init_turbo 0
over_voltage 0
sdram_over_voltage 0
force_turbo not selected

Does OSMC load a custom profile out of the box? I loaded OSMC from NOOBS. Maybe that accounts for the “wrong” profile?

I selected the “Normal” profile, which changes the reported arm_freq to 900 and core_freq to 450. The reported arm_freq appears to be incorrect, but I think I remember reading somewhere here that “Normal” actually does load the correct number for the Pi3. Is that right?

Anyway, after choosing “Normal”, the “hanging” problem was much improved but didn’t go away completely.

Yes, I’m using the OSMC dongle. As you know, I had a lot of trouble getting it working, and I was really hoping those troubles were over!

I just checked the 5G connection speed with an app on my cell phone in the same room as the Pi and the laptop and got 90 Mbits/sec averaged over one minute, so three different devices are connecting in this speed range, which tells me that’s probably all I’m going to get with this router. If I plug my laptop directly into the router, I get about 900 Mbits/sec. I haven’t measured the connection speed with the Pi when connected via ethernet, but I could with some difficulty. I’ve asked AT&T, who provides my router/gateway, why I’m not getting better wireless local connection speed, but I’ve not gotten any response so far.

Regardless, note that I don’t get the hanging/buffering behavior with the laptop watching the same program, connecting apparently at a similar speed. Is this sounding like another dongle problem?

Another item possibly worth noting: I have recorded programs on two different drives on the backend. I noticed this morning that if I don’t explicitly add the source from a drive to Kodi on the laptop, none of the programs on that drive appear on the laptop. (I noticed this when I tried to watch the same program on both devices.) With OSMC, as long as I’ve added the drive/folder as a storage location in NextPVR, all the programs on it show up for viewing in OSMC, without explicitly adding them as sources. I’m wondering now if I should explicitly add my recorded TV drives/directories as video sources in OSMC using fstab?

Thanks very much for the help!

I don’t know about NextPVR but with TVHeadend as long as you don’t mess with the location where you store recordings, all clients will find it. If you change that location, then yes you will have to add the old location as a source and access the recordings as Videos, not through the PVR client.

Yes. MyOSMC overclock presets have not been reconfigured since the release of the Pi3. Work is being done on MyOSMC 2.0, hence the reason we’ve done nothing to resolve the issue yet. OSMC does not default to custom. Someone changed your config locally.

# NOOBS Auto-generated Settings:

Looks like NOOBS is the culprit.

Thanks for the feedback. What I noticed about NextPVR is that, if I have Kodi installed on Windows, then Kodi will not find the recordings even if I haven’t moved them unless you add the location via a share. On OSMC, I’ve found that not to be the case; i.e., OSMC behaves with NextPVR the same way it behaves as you report with TVHeadend.

What I’m wondering is if there is a performance hit I’m experiencing that manifests in the buffering behavior I’m experiencing on seek step back as a result of how OSMC is navigating to the recorded TV programs. They’re SMB shares, I think.

Thanks again for the assistance.

1 I’m not sure of its importance but did you see the line in the snippet of messages that says Update NextPVR to v3.4?

2 I’d recommend that you install the crda package:

sudo apt-get update
sudo apt-get install crda

then edit file /etc/default/crda and set REGDOMAIN=US and reboot.

3 Is there any way you can monitor connections on the NextPVR end?

I did see that, and it prompted me to update NextPVR, except 3.4 is very old. I updated to 4.1 (I was at 4.0.something). The problem continues. Should I try to downgrade to 3.4?

I can certainly do this. Could you help me understand what it will do? I did a web search and the description I’m finding is pretty cryptic. (I’m almost illiterate in Linux.) Is OSMC setting my region incorrectly, and does that account for my connectivity issues? (Or is that the current hypothesis?)

How do you recommend I do this? Do you recommend going through my NextPVR logs to see if I can find connections issues?

Thanks very much for your help.

No. Stay on the latest.

CRDA tells the kernel what’s allowable in terms of available channels, etc. We’ve found that it sometimes helps when people are experiencing WiFi stability issues.

Well, it’s your server, so I don’t know anything about it. But logs have to be a good starting point.

Hi again,

I installed CRDA, set REGDOMAIN=US and rebooted. Between that and fixing the underclocking problem, the “hanging” on skip step back is improved but still present.

This seems like a different problem to me from “regular” buffering since I have no issues with playback at all – at least so far. Every now and then I’ll experience “buffering” when viewing Live TV but it’s quite rare, and I really don’t use the system to view Live TV anyway.

I just did another set of iperf tests using my backend computer as the server and the Windows 7 laptop, my Android cell phone, and the Pi as clients. This time, over 60 seconds, I averaged about 30 Mbits/sec with the laptop, 55 Mbits/sec with the Pi, and 65 Mbits/sec with the Android cell phone. So this time, the laptop had the slowest bandwidth but still experiences no hanging on seek step backward.

I’ve checked the NextPVR logs and found nothing untoward in them. Perhaps my next step should be to install TVHeadend? It seems like lots of people here use it.

Thanks again for the help.

Ok, probably progress.

You need to see if those connection errors are still appearing in the Kodi log.

Your cache size is only 20 MB. I suggest something closer to 100 MB would be more appropriate. Create a file /home/osmc/.kodi/userdata/advancedsettings.xml (without sudo) and add these lines:


then either reboot or restart mediacenter.

This morning I activated logging, rebooted, then accessed a recorded program and watched for a bit. I did some forward and backward seek/step an observed some hanging/buffering issues. Then I uploaded the log:

I scanned the log myself and found a couple entries I found interesting:

Another problem with the wifi dongle?

Mar 13 09:13:13 RPi3OSMC1 kernel: /mnt/package/kernel-osmc/src/linux-4.14.15/drivers/net/wireless/mt7610u/os/linux/../../chips/mt76x0.c:2114 assert (pAd->TxPower[choffset].Channel == 36)failed
Mar 13 09:13:13 RPi3OSMC1 kernel: ERROR!!! 
Mar 13 09:13:13 RPi3OSMC1 kernel: E2PROM: WRONG VERSION 0x2, should be 1

Something wrong on the backend with timers?

09:13:53.909 T:1519289088   ERROR: CPVRTimerInfoTag: no epg tag given for epg based timer type (5)!
09:13:57.267 T:1698689792   ERROR: Previous line repeats 92 times

There are a few other “error” entries in the Kodi log, but they don’t look suspicious to this amateur. In particular, I didn’t see any connection issues from this morning’s exercise.

Then there is a log section entitled “Kodi Old Log” that’s full of connection issues, but I’m not sure when those errors occurred. It seems like these errors might have occurred when my backend was asleep. Looking at the time in the log we looked at previously (near the top of this thread), it seems like those errors occurred while the backend was sleeping too (2:00). Could the Pi be trying to wake my backend for recording and failing? That’s not necessary in any event. The backend wakes up when necessary all by itself.

I haven’t attended to the buffer size yet. I thought I’d put this out there first.

Many thanks for your patience and assistance!

I went ahead and added the file as you prescribed, rebooted and tested. I’m still getting buffering on seek step backward.

Not sure if this is relevant, but if I “rewind” (keyboard “r”) I get no buffering or hesitation.

Again, thanks for your help.

Just to be clear, are you using skip steps, rather than fast-forward and rewind? (The latter are very inefficient and require too much network bandwidth.)

Yes, I’m using skip steps (keyboard comma or left arrow) and getting buffering/stalling (on skip back only). When I use rewind (keyboard r), I don’t get buffering/stalling. Are you saying I ought to be observing exactly the opposite?

Thank you.

I’ve been digging around some more here and I’m afraid I missed a relevant post here. In that post, there is a reference to a Kodi bug. There has apparently been no resolution and no reported activity since April 2017.

I apologize for missing this.

Excellent spot. I wasn’t aware of this issue, not having TVHeadend myself.

So main issue of this thread has been explained, though not fixed. Is there any secondary issue from this thread that you’d like keep active?

Edit: The second (bug) thread has a post with this:

I confirm the same behaviour…it happens with MMAL and not with OMX or software decode.

So did you try it with OMX?

No, I don’t think there are any secondary issues to keep active. I think we can close this out.

I missed the reference to OMX in the bug report. I’ll dig around and try to figure out how to use it. Am I using MMAL now and don’t know it ?

Thank you again!