Timeshift: buffering / stuttering after seeking in timeshift buffer #319
Comments
|
Just want to add that the same happens at windows too and overall it is not really stable to seek at timeshifted playback. Like said this is nothing new, never worked for me regardless of Tvh version. Everything beside pause/play is not use able. There were timeshift related fixes at Tvh in the past that made it much better, I am not too sure if the current situation isn't maybe due an Tvh server related bug. |
|
Not only if you try to rewind... Make a recording and than start viewing from start after 5 minutes. Use kabel1 or any other non-hd channel. When advertising start... wind over the advertising... when you reach the end of the recording the picture end with artefacts and sound issues. It never recovers. From logs i see ffmpeg causes out of order packets. The only workaround is stopping play and restarting. This is 100% reproducible. I have never seen this with openelec v6 or v7. This started with libreelec v8 from my point of view. |
|
I also have the exact same Problem. Is there any news or possible workaround? |
|
I'm seeing the same issue on Kodi 17 and Kodi 18b4, with tvheadend 4.2 and 4.3. Is this a known issue, or are there workarounds? |
|
Hello, The storage is a CIFS network mount. See attachment dvr and profile configurations for tvheadend settings in use for the recordings. Matroska profile without webm. This is reproduced on latest builds of kodi, kodi-pvr-hts and tvheadend stable on 32bit GNU/Gentoo running on raspberry pi 3B: Linux ARM 32-bit version 4.19.6-v7+ pvr-hts-tvheadend.settings.txt Thank you, |
|
Last days I've upgraded Kodi from v17 to v18. Kodi and tvheadend are installed on same Lubuntu 18.04.2 system. I was using stable releases, but after getting issues I've changed to unstable release. This issue is still there. Software: Hardware: Together with kodi v18, also this addon was upgraded. I've asked on kodi forum. The user FernetMenta helped me, he says that either tvheadend or this addon is causing my issues. |
|
@davincino I have the exact same problems with time shifting in kodi v18 (was fine in krypton). It's also reported here: https://forum.kodi.tv/showthread.php?tid=325178 |
|
I'm hoping that this commit in master will improve things. No yet tested
myself.
f6d248a#r32349769
Cheers
Dietmar.
Am Mi., 20. Feb. 2019 um 13:16 Uhr schrieb jahutchi <
notifications@github.com>:
… @davincino <https://github.com/davincino> I have the exact same problems
with time shifting in kodi v18 (was fine in krypton).
It's also reported here: https://forum.kodi.tv/showthread.php?tid=325178
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#319 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGGqKdd5Qif5OIUSiHYTnzSjlAL-kUhtks5vPTyogaJpZM4OZWv9>
.
|
|
FTR: I am using pvr.hts v4.4.13 against leia 18.1. |
Latest is 4.4.14, which contains the (potential) fix. |
|
Technically, two different problems:
Should be fixed in 4.4.14
No fix available yet. As far as I know this only happens with 720p channels (like German "ZDF HD" or "Das Erste HD"). There are rumors that this is caused by a tvheadend bug (I-frames handling when timeshifting or the like), but it's only rumors... |
|
v4.4.14 is included in Ubuntu nightly repo. I will test it later, when I'm at home. |
|
Tvheadend with timeshift enabled is extremly unstable. It crashes with both in memory and to disk mode. I was forced to disable it completly as all at home have seen crashing tvheadend and kodi every few hours. Cvh has confirmed this is known, but not that massive. He told me he has no issues with in memory only, but I cannot confirm this. This issues exists for an long time in libreelec. Aside this is not only ZDF, this ia also on every other private like pro7/rtl/vox and so on. An htpc without timeshift is really a useless device. I disabled all timeshifting and libreelec run fine for weeks in a row without a reboot. Every few weeks kodi crashes for other unknown reasons and auto restarts. |
|
I've installed latest version 4.4.14 |
|
@alexhass whatever your massive problems with timeshift are, those have other root cause than the problems discussed in this issue. This is about single buffering and continuous micro stuttering with 720p channels after pausing/rewinding. It makes no sense to use this issue to report all kind of timeshift problems. Please refrain from this and open a separate issue where you describe in detail what your problems are and where you attach a debug log file with pvr.hts trace enabled and service.log form tvheadend. Thanks. @davincino thanks for reporting back. |
|
I've also upgraded to v 4.4.14 and timeshift is working perfectly for me now too. Thanks @ksooo for this, and all the great work you do. |
|
@ksooo: yes, it is tvheadend that is crashing. Collecting logs is impossible as tvheadend crashes and than auto restart. When it auto restarts the logfile with crash information is overwritten and therefore lost. No chance to identify the crash. There is no logfile rollover or keep the last logfile in libreelec... |
|
If tvheadend is crashing, then this issue is the wrong place to report this. You should instead open a ticket for tvheadend at tvheadend.org. |
|
@jahutschi thanks for reporting back and for the nice words. You're welcome. 😀 |
|
Should we consider this closed if things work better in 4.4.14? |
|
I'm using 4.4.14 and after skip back the system is not buffering anymore. But sometimes (not reproducible) live tv is stuttering after some minutes. |
|
Like @ksooo wrote, I actually reported two issues here and the really annoying one still stands, unfortunately: the stuttering in Timeshift with 720p channels (after some minutes watching). I'm still testing with the new 4.4.14, tvheadend master. Keeping the fingers crossed to get this finally sorted our. Last major bug in this solution IMHO. |
|
see my comments here: #403 this change is actually not a proper fix because it does not allow the demux buffer to be filled in timeshift mode. |
|
@FernetMenta imo we are talking about two issues with different root cause here. The buffering after skip back is the one "fixed" with 4.4.14, people confirm the fix working. The continuous stuttering with only 720p channels after pausing/unpausing live tv is unrelated to the 4.4.14 change. There are people out there claiming they have debugged tvheadend and found that the issue is there. Don't know any more details about that story, sorry. |
|
btw, also reported to tvh, https://tvheadend.org/issues/4831 |
|
Nobody at the tvheadend side seems to care... :-/ |
|
Well, Kai. ;-) Cheers |
|
Dietmar, you're right that 720p is not that relevant outside Germany, because other countries -as well as private stations in Germany- are using 1080i50. But does this issue not occur in higher resolutions, e.g. the mentioned 1080? I always assumed it is related to higher data rates? |
|
Nope, 1080i streams are working fine without that issue, at least here with my setup. |
|
There is no 720p problem, but there are probably litttle problems with the specific encoder settings. From my investigation, German 720p channels do really heavy video (H264) frame reordering (up to one or two seconds) to save the bandwidth and it seems that the player code is confused (DTS/PTS). Unfortunately, we are doing a bit ping-pong here, because everytime when I ask for the timing details where things are breaking about the player the answer is - other PVR backends are fine, so find the bug yourself. And no, I don't use kodi in my environment (sorry). |
|
From your explanation, 53738.244000 = 53.738244 seconds, right? The frames for elementary stream 1 (video) are written here to the next layers (htsp server): 2019-02-26 16:39:28.107 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type P pts 53838266 dts 53738244 dur 1800 len 68719 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53798266 dts 53758244 dur 1800 len 43327 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53778266 dts 53778244 dur 1800 len 2048 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53818266 dts 53798244 dur 1800 len 512 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type P pts 53918266 dts 53818244 dur 1800 len 68338 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53878266 dts 53838244 dur 1800 len 42986 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53858266 dts 53858244 dur 1800 len 2053 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53898266 dts 53878244 dur 1800 len 523 time 55018266 2019-02-26 16:39:28.108 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type I pts 53998266 dts 53898244 dur 1800 len 124548 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53958266 dts 53918244 dur 1800 len 50528 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53938266 dts 53938244 dur 1800 len 2496 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 53978266 dts 53958244 dur 1800 len 83 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type P pts 54078266 dts 53978244 dur 1800 len 84028 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 54038266 dts 53998244 dur 1800 len 44386 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 54018266 dts 54018244 dur 1800 len 2302 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 54058266 dts 54038244 dur 1800 len 98 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type P pts 54158266 dts 54058244 dur 1800 len 65425 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 54118266 dts 54078244 dur 1800 len 41938 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 54098266 dts 54098244 dur 1800 len 2050 time 55018266 2019-02-26 16:39:28.109 [ TRACE]:timeshift: ts 12 pkt out - stream 1 type B pts 54138266 dts 54118244 dur 1800 len 552 time 55018266 So it seems that B-frames are somewhere dropped. The HTSP protocol has another feature which drops the frames/packets when a threshold is reached and it starts with the B-frames. Could you retest with this patch? diff --git a/src/htsp_server.c b/src/htsp_server.c
index a7f8a79e0..f1ed9ba1d 100644
--- a/src/htsp_server.c
+++ b/src/htsp_server.c
@@ -4017,7 +4017,7 @@ htsp_stream_deliver(htsp_subscription_t *hs, th_pkt_t *pkt)
return;
}
- if(video &&
+ if(0 && video &&
((qlen > hs->hs_queue_depth && pkt->v.pkt_frametype == PKT_B_FRAME) ||
(qlen > hs->hs_queue_depth * 2 && pkt->v.pkt_frametype == PKT_P_FRAME) ||
(qlen > hs->hs_queue_depth * 3))) {
Or pvr.hts can set the "queueDepth" parameter in the subscription method. The default value is 500000 which seems to be a bit small for fast forward (speed 400% or more). |
|
Thanks @perexg. What would be a good value for "queueDepth"? |
|
pvr.hts already sets "queueDepth" to 2000000. https://github.com/kodi-pvr/pvr.hts/blob/master/src/tvheadend/Subscription.cpp#L138 Is this still to small? Again, what would be a good value? |
What about tvh patch? Does it work? |
Sorry, bed time here. If you find some time for testing I would be glad to hear from you. |
Right. Away from my systems during the day. Can do further tests in the evening. Note that I already run modified versions of Kodi and pvr.hts that have corrects some weaknesses. |
Would be great if you could PR those fixes, so that all users can benefit. Thanks. |
|
With a tear in the eye I really feel that the problem is finally fixed. Snief. ;-) Actually this issue was quite easy to duplicate with my setup. After applying the patch on my tvh server I'm unable to do so... and I tried a lot this morning. So, folks. Looks like you finally did it. At least I hope so, I'm quite confident. |
|
Looking again to the collected logs, I think that we are missing the "big picture" for the data streaming when the timeshift is activated. The full queue is just a symptom that the server/client sync is broken. If we look to the tvh logs from comment , this type of operations are done:
It looks that the problem is that tvh sends a lot of data to the client when speed=400% (very visible at 16:39:26 and 16:39:28). I am looking further to logs to analyze the issue. |
Nope, the patch is just a workaround for the real issue. You may hit other wrong behaviour with it. |
|
Jaroslav, thank for looking into it. |
|
@perexg Kodi sets speed to 400 in timeshift mode when it wants to fill its internal buffers. It could read even faster but AFAIK tvh would turn into keyframe mode then. |
Then it looks like a protocol "misuse", but it explains the behaviour. I found another 100%->400% change and added it to the table. Each speed change sets the new time threshold (the client time), so if the client does 100%-400%-100%-400% rapidly, tvh sends a lot of data (there is build-in one second ahead threshold which is multiplied by the speed, too). There's some delay between data delivery, but it seems that kodi issues the new speed change request before it waits for the new data, thus they are buffered in the tvh (and dropped due to the congestion filter). Personally, I am not happy with the current timeshift protocol at all (I inherited it from the past and occasionally trying to fix it). It is somewhat difficult to compute the client expectations (how many frames should be sent ahead and especially track the actual client position - from logs, you can see the big desync - the server sends much more data ahead and other parts in tvh starts to protect the total network congestion). We have several ways to resolve this. The easiest way is to remove the current protocol and use the polled one (which you somewhat simulate), like - I want elementary streams from DTS A to B (or PTS as you like). Done. No states, no double position tracking, easy to implement on the server side. This will move the data flow arbitration completely to the client as you probably expect. |
sounds good imo |
|
@perexg @FernetMenta the 720p stuttering also occurs on changes 100->0->100, not only on changes 100->greater 100->100. So, no heavy data traffic needed to run into the problem, imo. Does this fit into your problem analysis and the derived idea for solution?
Just a headsup that I have no clue how to implement that. Somebody else would need to do this. |
|
I can do pvr.hts once tvh provides this new interface. @perexg do you have time to implement this in the near future? |
|
@ksooo in the meantime you can fix pvr.hts/src/tvheadend/HTSPDemuxer.h Line 119 in bd64b9e pktBuffer silently eats packets received from tvh. By default it can buffer 100 packets which is not much considering that channels like ZDF have at least 2 audio streams + teletext + subtilte + video. |
Great.
What would be a good value? |
https://github.com/kodi-pvr/pvr.hts/blob/master/src/tvheadend/HTSPDemuxer.cpp#L47 => paket buffer should be large enough already |
|
@FernetMenta : Please, ensure also that you don't do the 100-400-100-400 transitions quickly (wait for the answer and probably use speed 0 (pause) if there are many packets in the client's queue - you can check the real time for it). As I said, the increased buffer is just a workaround and it affects the memory usage on the server. |
Hehe, im not the author of that code in case you wanted to ask... 😀 |
|
Been following this one since i'm experiencing very unrelyable timeshifting with my IPTV setup. Been trying to nail down if this really is the same, but as with @dkonerma i have alot of (swedish) streams in 720p. I'm running TVHeadend 4.3-1792~g466a01431 (2019-05-20T17:02:26) and KODI client (leia) with latest official pvr.hts. What i'm wondering is if this patch/fix is included in that build of TVH? Have tried to verify but guess my git-knowledge fails me here :o |
|
ksooo increased queueDepth to 10000000, see Cheers |
|
Thanks Dietmar! I think i run 4.4.17. Cannot verify from work now. But that was the workaround part, right? Was there no fix in TVH by @perexg aswell? |
|
No, no fix in TVH so far. Increased queue depth size in pvr.hts seems to solve the problem. At least I have not heard anything else so far. |
|
Is this still an issue with latest Kodi v19 nightly builds and tvh 4.3+? If I get no response within two weeks, I will close this issue. |
|
Hi ksooo,
working fine here. Feel free to close and many thanks for your efforts!
Cheers.
Kai Sommerfeld <notifications@github.com> schrieb am So., 10. Jan. 2021,
23:01:
… Is this still an issue with latest Kodi v19 nightly builds and tvh 4.3+?
If I get no response within two weeks, I will close this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABQ2UKNOT6I5YUN3XCVFQWDSZIPTXANCNFSM4DTFNP6Q>
.
|
Hello,,
I'm using Kodi with TVH for many years now... and observed that timeshifting was never stable for me. Currently I'm using the latest Milhouse LibreELEC Leia build (#0715) with almost latest TVH. Bleeding edge though.
Timeshifting is failing completely for me on German channels like ZDF HD and ARD HD: These are 720p, whereas most other HD channels are 1080i and timeshift a lot better, not perfect also.
Example:
When I skip back into the timeshift buffer while watching ZDF HD 720p Live, then - after some seconds timeshifted playback - Kodi starts buffering ("busy circle") for several seconds. Afterwards playback resumes, but heavily stutters every few seconds. I also heave artifacts then, unwatchable. Skipping forward into LiveTV mode fixes the issue immediately.
When I do the very same with e.g. SAT1.HD 1080i, then I also see the buffering, which is annoying. But afterwards all is fine and watchable most of the time.
Here is a log of Kodi while doing the above steps.
http://sprunge.us/QIKE
Issues like these tend to bounce around between Kodi, PVR addon and TVH. Unfortunately Kodi Video folks (VDR promoters) don't really like to help wih TVH issues, IMHO. ;-)
Hope I can start the process to look into these issue here, in the "DMZ" between Kodi and TVH? ;-) Because Kodi with TVH is such a lovely solution... and stable timeshifting is the little remaining open issue before it gets nearly perfect.
Thanks
Dietmar.
The text was updated successfully, but these errors were encountered: