no. last test was with 17.8-407 about 18hours ago. I only see 406 here but thats what apt/history.log tells me.
I think you better start a sepperate topic related to the sound issue, since I havenāt seen anyone else with only DD+ issues.
Post a debug log with it as well, there should be topic about all the usefull info to help troubleshooting somewhere in support (couldnāt find any pinned topic about it, else I would have linked it).
It feels strange no one else has that problem, I have a pretty standard setup.
Iāll open a seperate topic. (I posted the log already btw. )
Has anyone else tried time shifting in tvheadend (pvr.hts) on the Vero 4k+ using these test builds?
Iām finding that if Iām watching TV and hit the āStep Backā (left) button a few times, then the picture goes extremely juddery. Itās extremely easy to reproduce for meā¦ happens every time.
I can stop the juddering by hitting pause, waiting a few seconds, then hitting play; so I can use this as a workaround in the meantime.
Timeshift is fine on other clients in my setup, when accessing the same TVheadend 4.2.5 server, those clients do not have this problem:
- Generic HTPC running Kodi 17.6 under LibreELEC 8.2.5
- RPI3 running Kodi 17.6 under LibreELEC 8.2.5
I wonder if this is one of those things that will improve when all patches etc. have been merged, as part of working towards the āOfficialā v18 builds?
I didnāt even know that was possible! You mean expected behaviour is to timeshift to an earlier point in the stream?
Yes itās configurable in the TVHeadend backend. Here are the settings I use. Iāve adjusted these over time and find that for my server, these are the most optimal settings.
Thatās correct, when timeshift is enabled then it should be possible to timeshift to an earlier point in the stream.
Just to re-iterate, it does timeshift but playback goes extremely stuttery. The stuttering can be corrected by hitting pause, waiting a couple of seconds, then hitting play.
It only seems to go stuttery if I step back whilst live tv is in operation (note: Iām using step back not rewind, as I know rewind is pretty broken).
Happy to open a new thread on this with logs if thatād be bestā¦ Just wanted to see first whether other TVheadend users using the Leia builds have tried this, and what success theyāve had.
Note: I did not have this problem on the Vero4K+ when running Krypton stable 17.6. But had other problems (hence why Iāve moved early to Leia): https://discourse.osmc.tv/t/problems-with-livetv-stuttering-on-vero-4k
OK thanks, Iāll go and check with @gmcās latest. My backend must be OK as itās working as you describe with a Windows front-end.
Updated to 18.1-RC1 and PVR is well broken even without timeshift. I get about one frame/second. Will investigate further.
For me, LiveTV is working nicely on my Vero4K+ with v17.8-406, itās just the time-shifting I have a problem with. I am testing with ITV HD.
OK. Turns out my vero had fallen back to 2.5G wifi after the re-boot. So with a decent connection I get:
- on HD, after skipping it stutters for a while, then I get some buffering then all is fine
- on SD there is no immediate major stuttering and no buffering but I get little stutters from time to time
- SD quality generally seems worse than on Krypton - needs more testing
- HD on Windows (I only tested SD before) is stuttery generally [update: itās the same with Krypton on Windows]
- SD on Windows has annoying combing I never noticed on Krypton [update: yes, combing is not there with Krypton on Windows]
Seems there are issues with Kodi here.
sounds very much like this one ā¦
no fix yet - neither on OSMC (amlcodec) nor Tvheadend side.
Out of interest, tested it with TVH 4.2.7 (on my Synology) and the latest nightly update of OSMC right before the test now with the free 4k stream from Astra 19.2E:
- fast rewind and immediately play again, no problem identified as much as Iām concerned.
- Skipping back to the start of the timeshift with the left button seems like it stalled for a short time but afterwards played flawless. Most likely what graham identified that Kodi is bulding up buffer (but without indicator).
Agreed, my observation is that the timeshift buffer needs time to stabilise.
If I do this:
- Play a TV Channel for a couple of minutes
- Hit step back a couple of times
- Immediately Hit Pause
- Wait 2-3 seconds
- Hit Play
Then the playback is perfect.
If I donāt perform steps 3, 4 & 5 then playback is choppy and unwatchable.
I wonder whether there is some way the code needs to be improved; e.g. to wait for the video buffer to fill sufficiently prior to resuming playback following a timeshift.
Has Timeshift ever worked well on TVH? I know itās been in a pretty broken state before.
Does hardware acceleration (enabled / disabled) make a difference?
Before buying a Vero 4K+ I used the following:
- Generic HTPC running Kodi 17.6 under LibreELEC 8.2.5
- RPI3 running Kodi 17.6 under LibreELEC 8.2.5
I still have those two machines running (against the same TVH server), and timeshift works well there.
I think it worked well on the Vero4K+ when I was running Krypton v17.6, but I canāt actually swear to that.
I have hardware acceleration enabled.
If I disable H/W accelleration, then the situation is worse (canāt cope with HD channels at all).
Can you try with SD?
This would let me know if itās possibly HW acceleration related.
Ive just been testing against an sd channel.
HW acceleration enabled
I have the same issue as with hd channels. If i timeshift then the video goes choppy and i need to hit pause then play to get things to return to normal.
HW acceleration disabled
Does not suffer same issue - i can time shift without issue. Playback is not as smooth as with acceleration enabled, but the smoothness doesnt get any worse after a timeshift
Testing Krypton on Windows - that seems to be what it does. Hit the back button and you immediately get buffering but then plays OK. With Leia I donāt get so much buffering, so things have changed but whether for good or bad is difficult to say.
17.8-408, 1 Feb 2019: Based off OSMC commit (02cb3d1a0f) and xbmc (c73401693)
XBMC:
- [cmake] fix policy CMP0053 (PR:15359, 1 commit, 1 file changed)
- [depends] remove unused platform lib (PR:15376, 1 commit, 2 files changed)
- [Demux] VP9 does not provide extradata (PR:15368, 1 commit, 3 files changed)
- [videoplayer] winrenderer: do scaling in output shader instead of yuv2rgb shader (PR:15382, 1 commit, 3 files changed)
pvr.mythtv:
- sync upstream cppmyth (2.12.1) (9a8b90c)
- bump version 5.10.5 (eaa4a50)
Includes latest addons: inputstream.adaptive (7688bb8, +1), inputstream.rtmp (ce7f559), peripheral.joystick (1f4225a), peripheral.xarcade (f09a0e7), pvr.argustv (83aa1e9), pvr.demo (964686d), pvr.dvblink (4ae42fe), pvr.dvbviewer(1ff63d4, +1), pvr.filmon (e850633), pvr.hdhomerun (a9d7309), pvr.hts (245df75, +4), pvr.iptvsimple (73feb2f, +3), pvr.mediaportal.tvserver (30c80ac, +1), pvr.mythtv (961d35e, +1), pvr.nextpvr (78c6633, +1), pvr.njoy (4467cac), pvr.octonet (203f800), pvr.pctv (b60b971), pvr.stalker (d0170c5), pvr.teleboy (1956113), pvr.vbox (ea20464), pvr.vdr.vnsi (cbb75ab), pvr.vuplus (bb6babc, +15), pvr.wmc (2697409), pvr.zattoo (ef6279f, +1), vfs.libarchive (6d39012), vfs.rar (0f56401), vfs.sftp (6749200)
anyone else notice 17.8-407 build has severe audio sync issues - starts ok but within a few seconds the a/v sync is all over the place. 404 seems to have the same issue, trying 399 next