Playback of recorded TV hangs on seek step backward

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!

It’s the default. From your log:

<usemmal default="true">true</usemmal>
<useomxplayer default="true">false</useomxplayer>

You can change it under Settings > Player Settings

Hi again,

I went to Settings > Player and selected "Allow hardware acceleration with OMXPlayer. That worked well for playing recorded programs – no more hanging with seek step backward, but it wouldn’t play Live TV. That seems to be a very common problem with OMXPlayer and there don’t appear to be any easy fixes for it. At least I haven’t found one.

While I look for a fix for Live TV, I switched back to “Allow hardware acceleration with MMAL” and, for some reason, I’m not getting stalling/buffering with playback of recorded TV now. I also deseclected “Allow hardware acceleration” for both. With that setting, I could see Live TV and seek step back without stalling. Probably just a coincidence and it will come back, we’ll see.

Thanks again for hanging in there with me.

If you haven’t tried already, you could also try with both MMAL and OMX enabled.

I hadn’t tried that. When I did, I could see live TV but I had buffering/stalling on seek step back. So, I tried all possible combinations and, for me deselecting both gives the best seek step back performance and I can see live TV although there might be a slight audio/video sync issue.

Not sure why deselecting both makes sense, but I’ll leave it that way for awhile and see what happens.

They allow video hardware acceleration. Deselecting both will probably run everything on the CPU. You can check using top if you’re thrashing the CPU.