Bug #2744
Tvheadend/Kodi crashes when ff/skipping to the end of the timeshift buffer
100%
Description
Hi,
I althoug posted this bug report to kodi forum (http://forum.kodi.tv/showthread.php?tid=219288) but I didn't get any response so I try it here again.
I'm experienc stability problems when ff/skipping to the end/beginning of the timeshift buffer.
Steps to reproduce:
1) start live TV
2) press pause an wait ~30 seconds
3) press play
4) fast forward until the picture freezes
from here on live tv doesnt work anymore. I can return to the menu by pressing the stop button (works with a few seconds lag)
LiveTV is unavailable until I restart TVheadend server (trying to play a new channel without restarting only shows "working....." for about 20 seconds)
My system specs:
Server:
Ubuntu 12.02 64bit
TVheadend Tvheadend 3.9.2509~ga50f74c
Clients:
Windows 7 64bit, Kodi 14.1, pvr-plugin v0.9.8
OpenELEC-Generic.x86_64-5.0.2
log files:
http://pastebin.com/xRpyg2gW <- server log
http://pastebin.com/GJ4DuS61 <- client log
If i could provide any other usefull information please let me know.
Thanks in advance Monchi
P.s.: Beside the stability issues TVheadend is greate piece of software! (for sure both server and client plugin are development versions )
Files
Subtasks
History
Updated by Martin Klayer over 9 years ago
Confirmed running Version 3.9.2525 on Synology.
In related Synology forum, someone said that the bug is fixed in 3.9.2526. Can someone confirm this?
Updated by ist dochegal over 9 years ago
no I cant confirme this. the bug is in 3.9.2662 still present
Updated by glenn ch over 9 years ago
I can confirm this, not actually a crash but it seems like the timeshift thread is hanging.
2015-03-28 00:02:06.013 [ DEBUG]:htsp: 192.168.1.110 [ xbmc-living | XBMC Media Center ] - subscription skip 2015-03-28 00:02:06.013 [ DEBUG]:timeshift: ts 17 eob revert to live mode 2015-03-28 00:02:06.013 [ DEBUG]:htsp: 192.168.1.110 [ xbmc-living | XBMC Media Center ] - subscription speed 2015-03-28 00:02:06.013 [ DEBUG]:timeshift: ts 17 deliver 72080905977 pts=1130200 2015-03-28 00:02:06.013 [ DEBUG]:timeshift: ts 17 deliver 72080945976 pts=1074388 2015-03-28 00:02:06.013 [ DEBUG]:timeshift: ts 17 deliver 72080945976 pts=1121200 several timeshift: ts 17 delivers later 2015-03-28 00:02:06.021 [ DEBUG]:timeshift: ts 17 deliver 72081813948 pts=1154943 2015-03-28 00:02:06.021 [ DEBUG]:timeshift: ts 17 deliver 72081813948 pts=1157103 2015-03-28 00:02:06.021 [ DEBUG]:timeshift: ts 17 deliver 72081825948 pts=1214800 2015-03-28 00:02:06.021 [ DEBUG]:htsp: 192.168.1.110 [ xbmc-living | XBMC Media Center ] - subscription stop 2015-03-28 00:02:06.021 [ ERROR]:timeshift: ts 17 could not read buffer 2015-03-28 00:02:13.490 [ DEBUG]:capmt: tvheadend, CA_SET_DESCR adapter 3 par 0 idx 0 01af5505318cfab7
Updated by Jaroslav Kysela over 9 years ago
Could you describe
- the exact timeshift settings (perhaps screenshot)
- exact sequence (stop stream, continue timeshifted, forward to.. etc.) - ideally, "--trace htsp,timeshift" would be best
Updated by ist dochegal over 9 years ago
- File debug.log debug.log added
- File tvheadend-ts-settings.PNG tvheadend-ts-settings.PNG added
Hi Jaroslav,
thanks for taking a look at this issue.
The excact sequence is:
1) start Kodi
2) start live tv (a few seconds)
3) pressing pause
4) wait ~10 seconds
5) pressing start - playback continues
6) ff (4 times normal speed)
7) lean back and wait for the crash ;-)
Updated by ist dochegal over 9 years ago
I don't know why the lines above are cancelled but they should NOT.
Updated by Stephan Schoemig over 9 years ago
Hello,
I have exactly the same issue on Tvheadend 4.1-114~gdb77f51 on a linux server and kodi on RP2 as client.. FFWD to Realtime freezes the picture. Tvheadend stays running and a Stop and restart of the programmen allows to resume watching.
This happens indepependant of any settings and of the pvr add-on.
I love tvheadend, just a robust timeshifting together with Kodi is missing to be the perfect TV solution.
Many thanks in advance to have a look on this.
Regards,
Stephan
Updated by Jaroslav Kysela over 9 years ago
I cannot reproduce on kodi 14.2, default (very old) pvr.hts plugin 1.9.39 . On FF to the end, I just get error messages, because the plugin keeps seeking, but tvh does not crash and the picture is only disjointed a bit, but it works.
Updated by Jaroslav Kysela over 9 years ago
I added to recent 4.1 code (master branch) more logging possibilities for the htsp protocol.
Could you compile tvh with --enable-debug and show the log for --trace htsp,htsp-req,htsp-ans,htsp-sub,timeshift when the problem occurs ?
https://tvheadend.org/projects/tvheadend/wiki/Traces
But if the issue is in the client, I cannot do much.
Updated by ist dochegal over 9 years ago
First of all thank your for your effort!
I tried to get the requested logs but I've failed. I compile the lastest code by this command
sudo AUTOBUILD_CONFIGURE_EXTRA='--enable-libffmpeg_static --enable-debug' ./Autobuild.sh -j4 -t precise-amd64
and recieved no errors. After installing I'm not able to start tvheadend. dmesg shows the following erros:
[ 5.267663] tvheadend1168: segfault at 0 ip 00007feb6ffe8a07 sp 00007fff6c802358 error 4 in libc-2.15.so[7feb6feb7000+1b4000]
[ 5.346885] init: tvheadend main process (1168) killed by SEGV signal
[ 5.346907] init: tvheadend main process ended, respawning
[ 5.584644] tvheadend1397: segfault at 0 ip 00007f93eb0c2a07 sp 00007fff3b178ac8 error 4 in libc-2.15.so[7f93eaf91000+1b4000]
[ 5.637179] init: tvheadend main process (1397) killed by SEGV signal
[ 5.637206] init: tvheadend main process ended, respawning
[ 5.881191] tvheadend1417: segfault at 0 ip 00007f8998d56a07 sp 00007fffeb70d928 error 4 in libc-2.15.so[7f8998c25000+1b4000]
[ 5.933314] init: tvheadend main process (1417) killed by SEGV signal
[ 5.933337] init: tvheadend main process ended, respawning
[ 6.169728] tvheadend1432: segfault at 0 ip 00007f2d693fba07 sp 00007fff1ef63668 error 4 in libc-2.15.so[7f2d692ca000+1b4000]
[ 6.222572] init: tvheadend main process (1432) killed by SEGV signal
[ 6.222597] init: tvheadend main process ended, respawning
[ 6.462365] tvheadend1447: segfault at 0 ip 00007f99e9e53a07 sp 00007fff72b5be08 error 4 in libc-2.15.so[7f99e9d22000+1b4000]
[ 6.513095] init: tvheadend main process (1447) killed by SEGV signal
[ 6.513120] init: tvheadend main process ended, respawning
[ 6.755203] tvheadend1462: segfault at 0 ip 00007fa14def6a07 sp 00007fff0fa6d4a8 error 4 in libc-2.15.so[7fa14ddc5000+1b4000]
[ 6.813460] init: tvheadend main process (1462) killed by SEGV signal
[ 6.813484] init: tvheadend main process ended, respawning
[ 7.050731] tvheadend1477: segfault at 0 ip 00007f833d74aa07 sp 00007fff5aca8fa8 error 4 in libc-2.15.so[7f833d619000+1b4000]
[ 7.102067] init: tvheadend main process (1477) killed by SEGV signal
[ 7.102091] init: tvheadend main process ended, respawning
[ 7.338594] tvheadend1492: segfault at 0 ip 00007f0429ba8a07 sp 00007fff5c6b24b8 error 4 in libc-2.15.so[7f0429a77000+1b4000]
[ 7.389783] init: tvheadend main process (1492) killed by SEGV signal
[ 7.389808] init: tvheadend main process ended, respawning
[ 7.634617] tvheadend1507: segfault at 0 ip 00007f08c3aeda07 sp 00007fff859150f8 error 4 in libc-2.15.so[7f08c39bc000+1b4000]
[ 7.693952] init: tvheadend main process (1507) killed by SEGV signal
[ 7.693977] init: tvheadend main process ended, respawning
[ 7.945588] tvheadend1522: segfault at 0 ip 00007f5d8dd6ca07 sp 00007fff3f2895e8 error 4 in libc-2.15.so[7f5d8dc3b000+1b4000]
[ 7.997217] init: tvheadend main process (1522) killed by SEGV signal
[ 7.997241] init: tvheadend main process ended, respawning
[ 8.285650] init: tvheadend main process (1537) killed by SEGV signal
[ 8.285675] init: tvheadend respawning too fast, stopped
any ideas?
Updated by ist dochegal over 9 years ago
- File tvheadend.log tvheadend.log added
- File tvheadend_noram.log tvheadend_noram.log added
removing the old configuration files resolved this issue.
by chance I found out that setting the maximal amount of ram used for timeshifting to zero prevents the crash.
Both log files (with max. ram 250MB, and max. ram 0MB) are attached
Updated by Andrew Gee over 9 years ago
- File tvheadend.log tvheadend.log added
Here's a debug trace log from 4.1-163. I paused, then resumed and skipped back 30s (at which point playback was fine for a while, then froze, then resumed). I then skipped to live, at which point playback froze and Kodi lost connection with tvheadend. This with the old Kodi plugin that comes stock with Openelec 5. I am happy to test with different plugins (I have adamsutton/negge's 0.9.8), different timeshift settings (currently RAM only, 2048M max) and different timeshift actions, but thought perexg would like to take a look at the logs first, and perhaps suggest the next useful test I could do.
Updated by Box Freak over 9 years ago
I also confirm this problem. Using latest stable Openelec with Chromebox and Sony PlayTV.
In addition I'm experiencing random freezing while playing back timeshift buffer. However it´s possible to resume playback after skipping forward or back. This happens quite often, every 2-3mins or so, so it´s quite annoying. My timeshift setting is always on (not on demand) and unlimited size and time. Buffer is stored on local SSD.
Updated by Eddsch K over 9 years ago
- File tvheadend_neu.log tvheadend_neu.log added
Hi guys,
I would like to help, because I love tvheadend and I need it. Timeshift is one of the best features, but since version 3.5 buggy :/. I have complied last week the software from Git-Masterbranch (HTS Tvheadend 4.1-360~g0916e52); OpenELEC 5.95.2.6.0 (Kernel 4.0.5); Kodi 15.0-Beta-2 Git:42fb669
Today I did some tests:
Here my proceeding:
39:00play 39:30pause 40:00play 40:30ff(2x) 40:45(ready?) 40:50video freeze 41:00could not read buffer
Log: (hope this helps)
38:55.167 - INFO Turning on
39:29.647 - change speed 0
39:55.004 - change speed 100
40:25.563 - change speed 200
40:50.306 - subscription stop
40:50.306 - could not read buffer
Here my timeshift-config:
Enabled: yes
OnDemand: no
OnlyUseRam: yes
Size: 2048
And my DebuggingConfig:
DebugTrace: yes
Debug subsystems: +all
Trace subsystems: htsp,timeshift,subcription,bat,pmt,pat
Please tell me how I can help in the future (Monday last exam (IT) and then vacation)
Eddsch
Updated by Eddsch K over 9 years ago
- File tvheadend_neu4.log tvheadend_neu4.log added
Here another try:
The only thing i changed is
Trace subsystems: htsp,timeshift,subcription,bat,pmt,pat,htsp-req,htsp-ans,htsp-sub
Maybe here is the "Unknown reason (1)"
Git src/streaming.c line 446
2015-07-24 12:26:45.831 [ DEBUG]:htsp: 192.168.178.30 [ kodi-wz | Kodi Media Center ] - subscription stop 2015-07-24 12:26:45.831 [ TRACE]:htsp-sub: 192.168.178.30 [ kodi-wz | Kodi Media Center ] - subscription 21 '{"method":"subscriptionStop","subscriptionId":21,"status":"Unknown reason (1)","subscriptionError":"Unknown reason (1)"}' 2015-07-24 12:26:45.831 [ ERROR]:timeshift: ts 143 could not read buffer 2015-07-24 12:26:45.831 [ TRACE]:timeshift: ts 143 exit reader thread
24:00 - turning on ARD
25:00 - pause
26:00 - play buffered
26:30 - ff(4x)
27:00 - buffer error; video freeze
27:30 - push play
Updated by Markus Hampel over 9 years ago
Hello,
same problem with 4.1-182~gfb6b56c and kodi 15.0 (Tvheadend HTSP Client 2.1.16).
Problem only occurs with RAM enabled (size > 0) in Tvheadend timeshift options.
Best,
Markus
Updated by Jaroslav Kysela almost 9 years ago
I fixed little issues in the timeshift code. If you like, please, report your results now (current 4.0 branch or the latest master - both have fixes in).
Updated by ist dochegal almost 9 years ago
Hi Jaroslav,
your code changes seem to improve stability at least. First test were successful. I'll do some extended testing next weekend.
Thanks!
Updated by Manfred Kreisl almost 9 years ago
Jaroslav, very good you are working on it, thanks for your work.
It works much better than before, no freezes for my first test. But it is still an adventure moving back and forward in the timeshift buffer.
Sometimes it happens nothing (no move forward or reverse, just continuing at the same position), and once it happens when I skipped forward it moved nearly to the beginning (not exactly to it) of the show. But no freeze and no crash.
Updated by Mark Clarkstone almost 9 years ago
Adding my experience with timeshift
Timeshift mostly works fine here however I have noticed that if you skip back and forth too often Kodi freezes and the only solution is to skip forward a little which unfreezes the picture and eventually catches up (It frame steps for a bit).
Updated by Jaroslav Kysela almost 9 years ago
Fixes for pvr.hts: https://github.com/kodi-pvr/pvr.hts/pull/146
Updated by Manfred Kreisl almost 9 years ago
Jaroslav Kysela wrote:
Fixes for pvr.hts: https://github.com/kodi-pvr/pvr.hts/pull/146
Hopefully theese patches will arrive soon in master branch so I can test it, because I did more testing and my result is: still completely unusable.
Updated by Martin Walter almost 9 years ago
I have built Jaroslav's pvr.hts fork (including those patches) into fritsch's OE 6.0 (15.2) EGL version because I was curious to see where things are going. Still having issues too. But I am missing some timeshift patches on the backend as I use J. Dierkse's cross-compiled Synology packages and 4.1.1233 is the latest there... Yikes!
Anyways, Jaroslav has been unusually quiet today, so there is some likelihood he has started rewriting the whole timeshift implementation from scratch...
Updated by Jaroslav Kysela almost 9 years ago
I have many timeshift changes in my tree, but I fight really tight with the Kodi video player which seems really picky on PTS changes (seeking) in the incoming stream and I've not analyzed completely the player's behaviour yet.
Updated by Jaroslav Kysela almost 9 years ago
All my timeshift changes/fixes/updates are in the current development v4.1-1276-ga27ed2e version. It looks really stable now. Also, the pvr.hts should be updated:
https://github.com/kodi-pvr/pvr.hts/pull/146 # kodi 15.2
https://github.com/kodi-pvr/pvr.hts/pull/155 # kodi master
Updated by Manfred Kreisl almost 9 years ago
Jaroslav,
I'm not sure what you are testing ...
I built the latest version (4.1-1276~ga27ed2e-dirty) and first try was using original Jarvis addon - skipping back kodi freeze and TVH crash...
So, then I tried to build a patched addon for Jarvis with your PR - compile error. Tried to fix the compile errors [1] and after successfully build, tried again:
Sometimes TVH crash, somtime extreme artifacts, sometimes kodi freeze - working: NEVER
[1] My changes I did in HTSPDemuxer.cpp for Jarvis addon
manfred@kmnote5:/usr/src/xbian/xbian-package-xbmc/build/os-jarvis/working/project/cmake/addons/build/pvr.hts/src> diff -u HTSPDemuxer.cpp HTSPDemuxer.cpp.new --- HTSPDemuxer.cpp 2016-01-01 18:52:38.279526232 +0100 +++ HTSPDemuxer.cpp.new 2016-01-01 18:38:05.897894185 +0100 @@ -48,7 +48,7 @@ if (m_subscription.IsActive()) { tvhdebug("demux re-starting stream"); - m_subscription.SendSubscribe(true); + m_subscription.SendSubscribe(0, 0, true); m_subscription.SendSpeed(true); /* Reset status */ @@ -192,7 +192,7 @@ CLockObject lock(m_conn.Mutex()); if (!m_subscription.IsActive()) return; - if (speed != m_subscription.speed && (speed < 0 || speed >= 4000)) { + if (speed != m_subscription.GetSpeed() && (speed < 0 || speed >= 4000)) { m_speedChange = true; Flush(); } @@ -536,7 +536,8 @@ uint32_t u32; if (!htsmsg_get_u32(m, "speed", &u32)) tvhtrace("recv speed %d", u32); - m_subscription.speed = u32; + //m_subscription.speed = u32; + m_subscription.SendSpeed(u32); if (m_speedChange) { Flush(); m_speedChange = false;
So my dissappointing result is: Still unusable
Sorry for this bad news, I wished a had better ones ...
Updated by Jaroslav Kysela almost 9 years ago
Updated by Manfred Kreisl almost 9 years ago
Hmmm, tested more with different clients.
Seems to work better after installing latest package kodi package and addons built tonight (using for testing now XBian on a Solidrun iMX.6 Hummingboard QuadCore 2GB RAM, Jarvis Beta 5), had only one TVH crash while using RPi1 with slightly older addons.
No crash of TVH so far, skipping reverse and forward ok.
Will do more tests.
Updated by Manfred Kreisl almost 9 years ago
More testes done (TVH version 4.1-1284~ga5085c8-dirty), result: extremely disappointing:
removed SendSpeed(), tested again with 720p channel: start playing for 5s - skip back - TVH crash
That's what I found in the log (test were done on a openSUSE 13.1 notebook as client):
Jan 2 02:00:54 kmcubie dvr: checking free and used disk space for config "Default profile" : OK Jan 2 02:00:54 kmcubie timeshift: ts 13 skip -2151000 requested -193590 Jan 2 02:00:54 kmcubie timeshift: ts 13 skip time -2151000 Jan 2 02:00:54 kmcubie timeshift: ts 13 skip to -2151000 from 4512000 Jan 2 02:00:54 kmcubie timeshift: ts 13 skip found pkt @ 1168177 Jan 2 02:00:54 kmcubie timeshift: ts 13 skip to -2151000 from 4512000 Jan 2 02:00:54 kmcubie timeshift: ts 13 skip found pkt @ 1168177 Jan 2 02:00:54 kmcubie timeshift: ts 13 skip to pts 1168177 ok Jan 2 02:00:54 kmcubie timeshift: ts 13 sob speed 100 last time 1168177
Other tests with XBian - no TVH crash but:
SD channel: seems ok, could not found an issue while short testing
HD channel 720p: sometimes ok, sometimes not, relability: 50%
HD channel 1080i: unusable, artifacts and freeze when skip forward/reverse, relability: 0%
(backend is a 1GHz Dualcore Cubieboard2 (vdr as PVR backend works perfectly))
Updated by Jaroslav Kysela almost 9 years ago
I'll dig more. The current implementation sometimes sends more data in one big chunk, so perhaps, some frontends on slower systems / network cards might have issues (1080i). I have other ideas what's wrong with the timeshift and implementation in my head, but the testing and analysing of the logs is very time consuming which blocks me from other work - 4.2 release (and I don't use kodi at all to watch TV - enigma2 simply wins here). And it's good to know that VDR has no issues!
Updated by Manfred Kreisl almost 9 years ago
Jaroslav Kysela wrote:
I'll dig more. The current implementation sometimes sends more data in one big chunk, so perhaps,
Fine, hopefully with more success than me
some frontends on slower systems / network cards might have issues (1080i). I have other ideas what's
Can not agree. Things are working worse on my faster notebook than on RPi & Co
wrong with the timeshift and implementation in my head, but the testing and analysing of the logs is very time consuming which blocks me from other work - 4.2 release (and I don't use kodi at all
Oh yes, that's true. So, everybody has own priorities.
to watch TV - enigma2 simply wins here). And it's good to know that VDR has no issues!
No Kodi? so I'm not wondering why timshift still works crappy :-)
I found a possibility to make it a little bit better:
Using a small memory cache for timeshift (100M) and 10G of disk space. With this settings 720p works better, but 1080i still unusable.
Yes, VDR works nearly perfect. My Cubieboard2 is able to stream one 1080i incl descrambling and one SD to different Kodi clients without any problems.
And still having TVH crashes, but unfortunately they does not appear under gdb
Updated by Jaroslav Kysela almost 9 years ago
Pushed many timeshift fixes to v4.1-1294-ga1b7002 . The packet clocks should be ok now with the maintaining of coherency (server-client) now.
Updated by Mark Clarkstone almost 9 years ago
Jaroslav Kysela wrote:
Pushed many timeshift fixes to v4.1-1294-ga1b7002 . The packet clocks should be ok now with the maintaining of coherency (server-client) now.
Tried latest master (v4.1.1298) with two kodi frontends.
Windows: 16.0 B5
Linux: 16.0 B4
Both using pvr.hts 2.2.10
It sort of works but it glitches like crazy then deadlocks gobbling up memory until I kill it.
Will continue to test
Updated by Jaroslav Kysela almost 9 years ago
I think that testing with the unmodified pvr.hts does not make sense, because it waits wrongly for the seek requests and uses old (invalid) stream packets after seek/skip requests.
Dead-loop - if you can provide some more details, it will be helpful. It's may be good to attach gdb to the task and run backtrace for all threads when memory goes high.
Updated by Mark Clarkstone almost 9 years ago
Jaroslav Kysela wrote:
I think that testing with the unmodified pvr.hts does not make sense, because it waits wrongly for the seek requests and uses old (invalid) stream packets after seek/skip requests.
Dead-loop - if you can provide some more details, it will be helpful. It's may be good to attach gdb to the task and run backtrace for all threads when memory goes high.
OK I've PMed you a link to the gdb trace on IRC as it may contain sensitive info :).
Updated by Alfred Zastrow almost 9 years ago
Sorry for missusing this bug thread.
Are there special reguirements to compile the modified pvr.hts? Are the Kodi sources or headers needed for this?
Updated by Jaroslav Kysela almost 9 years ago
Alfred Zastrow wrote:
Sorry for missusing this bug thread.
Are there special reguirements to compile the modified pvr.hts? Are the Kodi sources or headers needed for this?
You must install kodi-devel, platform-devel and cmake packages ... At least, it's for Fedora, not sure for other distros.
Updated by Manfred Kreisl almost 9 years ago
Here are my test results (Kodi Jarvis Beta 5, built today):
- Tested with 'original' pvr.hts (2.2.10):
Works much much better, it is now usable. sometimes artifacts and/or short locks (~2s) when skipping forward/reverse, but never freezes or crashes. Seems ok for my short test. Tested with 720p and 1080i, both were ok (/)
- Then tested with patched pvr.hts (2.2.11):
Still unusable with this combination - can confirm Mark's issue. After first skip back command, picture freezes, TVH's cpu consumptions goes up to 150% and eats more and more memory. After stopping the channel, memory usage did not rise but cpu usage was still 100%.
But, this changes are a big step in the right direction
Updated by Jaroslav Kysela almost 9 years ago
Use latest master - last timeshift bug was fixed in v4.1-1301-g25b2cbc . I need feedback for Jarvis / latest pvr.hts with changes from PR number 155.
Updated by Jaroslav Kysela almost 9 years ago
v4.1-1303-gbd69326 - rewind / fast-forward more 'interactive'.. Nearly perfect timeshift now...
Updated by Manfred Kreisl almost 9 years ago
Tested with 4.1-1302~g6fafa3b-dirty and patched pvr.hts:
After enabling option Fit to RAM (cut rewind) it works very well. Had one Kodi freeze, but this must not be related to TVH/timeshift.
Used a 1080i channel for testing. Only one small issue found: when skipping beyond buffers end, playing of the channel is not smooth, it stutters. After skipping back some seconds smooth playing is back.
Will test 1303 later
Updated by Jaroslav Kysela almost 9 years ago
Manfred Kreisl wrote:
Tested with 4.1-1302~g6fafa3b-dirty and patched pvr.hts:
After enabling option Fit to RAM (cut rewind) it works very well. Had one Kodi freeze, but this must not be related to TVH/timeshift.
It's just a storage option. It should not affect anything except the rewind time (basically, if timeshift is not used, only the system memory is used for timeshift packets without disk i/o).
Used a 1080i channel for testing. Only one small issue found: when skipping beyond buffers end, playing of the channel is not smooth, it stutters. After skipping back some seconds smooth playing is back.
I'm not sure, if it's not kodi player failure (small buffering which causes these hitches). Fast pause/play resolves this.
Updated by Manfred Kreisl almost 9 years ago
Now testing 1303:
SD channels seems ok, 1080i channels seems ok BUT: 720p channels are mostly unusable
Tested with different channels:- Das Erste: newer works, artifacts, freezes, nothing in TVH log [1]
- ZDF: does not work, artifacts, freezes, nothing in TVH log
- arte HD: works a little bit, after a while completely kodi freeze, have to kill it hard
- zdf_neo HD: only tested a bit, worked so far. But probably same issue like arte HD
[1] NO playing of this channel with enabled timeshift. After disabling timeshift playing of this channel is ok (tested with different clients)
Channel starts ok, after a few secons upcoming artifacts for 2s, then picture freezes and kodi writes "Buffering ...". Thats the end. Nothing in TVH's log (debug of timeshift is enabled)
Here kodi's log when this happens:
Jan 4 21:00:30 T:139984854050560 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available Jan 4 21:00:30 T:139984854050560 WARNING: Previous line repeats 1 times. Jan 4 21:00:30 T:139984854050560 DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1 Jan 4 21:00:30 T:139984854050560 DEBUG: Previous line repeats 2 times. Jan 4 21:00:30 T:139984854050560 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available Jan 4 21:00:30 T:139984854050560 DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 0 Jan 4 21:00:30 T:139984854050560 DEBUG: Previous line repeats 2 times. Jan 4 21:00:30 T:139984854050560 DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1 Jan 4 21:00:30 T:139984854050560 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available Jan 4 21:00:30 T:139984854050560 DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1 Jan 4 21:00:30 T:139984854050560 DEBUG: Previous line repeats 2 times. Jan 4 21:00:30 T:139984854050560 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available Jan 4 21:00:31 T:139984854050560 DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1 Jan 4 21:00:31 T:139984854050560 DEBUG: Previous line repeats 2 times. Jan 4 21:00:31 T:139984854050560 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available Jan 4 21:00:31 T:139984854050560 WARNING: Previous line repeats 5 times. Jan 4 21:00:31 T:139984854050560 DEBUG: CPullupCorrection: detected pattern of length 1: 20000.01, frameduration: 20000.000000 Jan 4 21:00:31 T:139986771412736 DEBUG: audio stream stalled. start buffering Jan 4 21:00:31 T:139986771412736 DEBUG: CDVDPlayer::SetCaching - caching state 2 Jan 4 21:00:31 T:139986771412736 DEBUG: CDVDPlayer::SetCaching - caching state 2 Jan 4 21:00:31 T:139987554670784 DEBUG: ------ Window Init (DialogSeekBar.xml) ------ Jan 4 21:00:31 T:139984854050560 DEBUG: CDVDPlayerVideo - CDVDMsg::GENERAL_SYNCHRONIZE Jan 4 21:00:31 T:139986771412736 DEBUG: CDVDPlayer::HandleMessages - player started 1 Jan 4 21:00:31 T:139985567069952 DEBUG: CDVDPlayerAudio - CDVDMsg::GENERAL_SYNCHRONIZE Jan 4 21:00:31 T:139986771412736 DEBUG: CDVDPlayer::HandleMessages - player started 2 Jan 4 21:00:37 T:139985889163008 DEBUG: Thread JobWorker 139985889163008 terminating (autodelete) Jan 4 21:00:37 T:139985592248064 DEBUG: Thread JobWorker 139985592248064 terminating (autodelete) Jan 4 21:00:37 T:139986762364672 DEBUG: Thread JobWorker 139986762364672 terminating (autodelete) Jan 4 21:00:37 T:139984845657856 DEBUG: Thread JobWorker 139984845657856 terminating (autodelete) Jan 4 21:00:38 T:139987554670784 DEBUG: ------ Window Init (Pointer.xml) ------ Jan 4 21:00:38 T:139987554670784 DEBUG: ------ Window Init (VideoOSD.xml) ------ Jan 4 21:00:38 T:139987554670784 INFO: Loading skin file: VideoOSD.xml, load type: KEEP_IN_MEMORY Jan 4 21:00:39 T:139987554670784 DEBUG: ------ Window Deinit (Pointer.xml) ------ Jan 4 21:00:42 T:139987554670784 DEBUG: ------ Window Deinit (VideoOSD.xml) ------ Jan 4 21:01:39 T:139987554670784 DEBUG: CAnnouncementManager - Announcement: OnScreensaverActivated from xbmc Jan 4 21:01:39 T:139987554670784 DEBUG: GOT ANNOUNCEMENT, type: 4, from xbmc, message OnScreensaverActivated Jan 4 21:01:39 T:139987554670784 DEBUG: AddOnLog: Tvheadend HTSP Client: pvr.hts - Announce(flag=GUI, sender=xbmc, message=OnScreensaverActivated) Jan 4 21:01:39 T:139987554670784 DEBUG: ------ Window Init () ------ Jan 4 21:02:27 T:139987554670784 DEBUG: CAnnouncementManager - Announcement: OnScreensaverDeactivated from xbmc Jan 4 21:02:27 T:139987554670784 DEBUG: GOT ANNOUNCEMENT, type: 4, from xbmc, message OnScreensaverDeactivated Jan 4 21:02:27 T:139987554670784 DEBUG: AddOnLog: Tvheadend HTSP Client: pvr.hts - Announce(flag=GUI, sender=xbmc, message=OnScreensaverDeactivated)
That's what TVH wrote in the log:
Jan 4 20:59:39 kmcubie htsp: 192.168.1.69 [ xbmc | Kodi Media Center ]: Disconnected Jan 4 20:59:41 kmcubie dvr: checking free and used disk space for config "Default profile" : OK Jan 4 20:59:56 kmcubie dvr: checking free and used disk space for config "Default profile" : OK Jan 4 21:00:04 kmcubie htsp: Got connection from 192.168.1.69 Jan 4 21:00:04 kmcubie htsp: 192.168.1.69: Welcomed client software: Kodi Media Center (HTSPv24) Jan 4 21:00:04 kmcubie htsp: 192.168.1.69 [ Kodi Media Center ]: Identified as user 'xbmc' Jan 4 21:00:04 kmcubie htsp: 192.168.1.69 [ xbmc | Kodi Media Center ]: Privileges updated Jan 4 21:00:10 kmcubie mpegts: 330MHz in dvb-c Home - tuning on DRXK DVB-C DVB-T : DVB-C #0 Jan 4 21:00:10 kmcubie subscription: 0023: "192.168.1.69 [ xbmc | Kodi Media Center ]" subscribing on channel "Das Erste HD", weight: 150, adapter: "DRXK DVB-C DVB-T : DVB-C #0", network: "dvb-c Home", mux: "330MHz", provider: "ARD", service: "Das Erste HD", profile="htsp", hostname="192.168.1.69", username="xbmc", client="Kodi Media Center" Jan 4 21:00:11 kmcubie dvr: checking free and used disk space for config "Default profile" : OK Jan 4 21:00:26 kmcubie dvr: checking free and used disk space for config "Default profile" : OK
Then, TVH crashed with following gdb message
tcp_server: tvhpoll_wait: Unterbrechung während des Betriebssystemaufrufs 2016-01-04 21:00:04.440 [ INFO] htsp: Got connection from 192.168.1.69 2016-01-04 21:00:04.440 [ INFO] htsp: 192.168.1.69: Welcomed client software: Kodi Media Center (HTSPv24) 2016-01-04 21:00:04.442 [ INFO] htsp: 192.168.1.69 [ Kodi Media Center ]: Identified as user 'xbmc' 2016-01-04 21:00:04.442 [ INFO] htsp: 192.168.1.69 [ xbmc | Kodi Media Center ]: Privileges updated [New Thread 0xa4dff170 (LWP 4916)] tcp_server: tvhpoll_wait: Unterbrechung während des Betriebssystemaufrufs [New Thread 0xa75ff170 (LWP 4917)] tcp_server: tvhpoll_wait: Unterbrechung während des Betriebssystemaufrufs 2016-01-04 21:00:10.656 [ INFO] mpegts: 330MHz in dvb-c Home - tuning on DRXK DVB-C DVB-T : DVB-C #0 2016-01-04 21:00:10.657 [ INFO] subscription: 0023: "192.168.1.69 [ xbmc | Kodi Media Center ]" subscribing on channel "Das Erste HD", weight: 150, adapter: "DRXK DVB-C DVB-T : DVB-C #0", network: "dvb-c Home", mux: "330MHz", provider: "ARD", service: "Das Erste HD", profile="htsp", hostname="192.168.1.69", username="xbmc", client="Kodi Media Center" [New Thread 0x9e7ff170 (LWP 4920)] tcp_server: tvhpoll_wait: Unterbrechung während des Betriebssystemaufrufs *** Error in `/usr/src/xbian/xbian-package-hts-mine/build/cb2/working/build.linux/tvheadend': malloc(): smallbin double linked list corrupted: 0x9e9ecc48 *** Program received signal SIGABRT, Aborted. [Switching to Thread 0xb05ff170 (LWP 1357)] __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 44 ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: Datei oder Verzeichnis nicht gefunden. (gdb)
Updated by Jaroslav Kysela almost 9 years ago
@Manfred: Enable the verbose debug log in pvr.hts plugin to see the incoming packets for 720p. Also "--trace timeshift" (tvh) might uncover something.
Updated by Manfred Kreisl almost 9 years ago
Updated by Manfred Kreisl almost 9 years ago
When TVH crashes, I always get the smallbin double linked list corrupted Error
[New Thread 0xa85ff170 (LWP 1333)] tcp_server: tvhpoll_wait: Unterbrechung während des Betriebssystemaufrufs *** Error in `/usr/src/xbian/xbian-package-hts-mine/build/cb2/working/build.linux/tvheadend': malloc(): smallbin double linked list corrupted: 0xa0c91960 *** Program received signal SIGABRT, Aborted. [Switching to Thread 0xb05ff170 (LWP 30603)] __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 44 ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: Datei oder Verzeichnis nicht gefunden. (gdb) where #0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 #1 0xb6c19ec6 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb6c1abce in __GI_abort () at abort.c:89 #3 0xb6c42d3e in __libc_message (do_abort=<optimized out>, fmt=0xb6cc12d8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #4 0xb6c46cae in malloc_printerr (action=1, str=0xb6cc1728 "malloc(): smallbin double linked list corrupted", ptr=<optimized out>) at malloc.c:4996 #5 0xb6c48834 in _int_malloc (av=av@entry=0xb6000010, bytes=bytes@entry=32) at malloc.c:3359 #6 0xb6c49a42 in __GI___libc_malloc (bytes=32) at malloc.c:2891 #7 0x0004757e in streaming_msg_create (type=SMT_PACKET) at src/streaming.c:180 #8 streaming_msg_create_pkt (pkt=pkt@entry=0xa0f9bd28) at src/streaming.c:195 #9 0x00071166 in parser_deliver (t=t@entry=0x944ce0, st=st@entry=0x945358, pkt=0xa0f9bd28) at src/parsers/parsers.c:1827 #10 0x00072bfe in parse_teletext (start=<optimized out>, len=<optimized out>, data=<optimized out>, st=<optimized out>, t=<optimized out>) at src/parsers/parsers.c:1779 #11 parse_mpeg_ts (t=0x944ce0, st=0x945358, data=<optimized out>, len=<optimized out>, start=0, err=0) at src/parsers/parsers.c:212 #12 0x0009a748 in ts_recv_packet0 (t=t@entry=0x944ce0, st=st@entry=0x945358, tsb=tsb@entry=0xb4f373a1 "G\023\360\022\002,\326\344@\250\364\250\250\250\250\250\250\343\214\r\354a\203J#/\247\037/\340#\227\004\r\255u\r\214u\214m\340\r\r]\r\235]\255\255\377,", '\377' <repeats 45 times>, ",", '\377' <repeats 45 times>, ",", '\377' <repeats 44 times>, "G\023\355\033f\210\331ٳ\346\321V"..., len=len@entry=188) at src/input/mpegts/tsdemux.c:104 #13 0x0009a936 in ts_recv_packet1 (t=<optimized out>, tsb=tsb@entry=0xb4f373a1 "G\023\360\022\002,\326\344@\250\364\250\250\250\250\250\250\343\214\r\354a\203J#/\247\037/\340#\227\004\r\255u\r\214u\214m\340\r\r]\r\235]\255\255\377,", '\377' <repeats 45 times>, ",", '\377' <repeats 45 times>, ",", '\377' <repeats 44 times>, "G\023\355\033f\210\331ٳ\346\321V"..., len=len@entry=188, table=0) at src/input/mpegts/tsdemux.c:246 #14 0x00099824 in mpegts_input_process (mpkt=0xb4f35d88, mi=<optimized out>) at src/input/mpegts/mpegts_input.c:1329 #15 mpegts_input_thread (p=0x82d108) at src/input/mpegts/mpegts_input.c:1460 #16 0x00039498 in thread_wrapper (p=0x9d9508) at src/wrappers.c:177 #17 0xb6d71f88 in start_thread (arg=0xb05ff170) at pthread_create.c:311 #18 0xb6c86ebc in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Updated by Jaroslav Kysela almost 9 years ago
I fixed crashes in v4.1-1314-gf1d7aab (100%) . The 720p is probably related - I found one channel in my environment which behaved like @Manfred described and it's fixed now.
Please, give feedback.
Updated by Manfred Kreisl almost 9 years ago
Works much better than before
Only get sometimes periodic artifacts on my crtical 720p channels. If theese artifacts happens, they does not go away, they appearing every 10s (skipping back/forward, pause/unpause did not solve this)
Seems that there are still small issues in the buffer logic. Tried different timeshift settings - no change in this behaviour.
But no Kodi freezes and no TVH crash.
Thanks for your work, Jaroslav
Updated by Jaroslav Kysela almost 9 years ago
- Status changed from New to Fixed
The picture artifacts are probably caused by the wrong decoding process (ffmpeg / kodi), see bug #3482 .
I'm closing this issue, because the main timeshift issues are gone. Please, create a new issue, when you hit another problem.
Updated by Manfred Kreisl almost 9 years ago
Ok, I also read this issue and tried deactivating VAAPI (I'm using a core i5 with VAAPI). This makes things better on this channel, but it still happens sometimes.
But this IS IMO timeshift related, if timeshift is deactivated those artifacts are away.
Updated by C K almost 9 years ago
Manfred Kreisl wrote:
Ok, I also read this issue and tried deactivating VAAPI (I'm using a core i5 with VAAPI). This makes things better on this channel, but it still happens sometimes.
But this IS IMO timeshift related, if timeshift is deactivated those artifacts are away.
Disabling timeshift and a restart of the stream fixed the artifacts.
Updated by Manfred Kreisl almost 9 years ago
With 4.1-1333~g196b1d9 theese kind of artifacts has been gone
Timeshift is now usable
Thanks
Updated by Wim K almost 9 years ago
Jaroslav Kysela wrote:
The picture artifacts are probably caused by the wrong decoding process (ffmpeg / kodi), see bug #3482 .
I'm closing this issue, because the main timeshift issues are gone. Please, create a new issue, when you hit another problem.
I'm new to tvheadend, so my apologies if I misunderstand. But over here, this issue "Tvheadend/Kodi crashes when ff/skipping to the end of the timeshift buffer" (title of this thread) is not solved.
This is my setup:
Backend:
HDHomerun, raspberry Pi2.
TVHeadend Build: 4.1-1434~g4fdd552 (2016-02-02T21:48:48+0100), compiled and build myself (with help).
TVHeadend Configuration, recording: timeshift not enabled.
Frontend
Kodi 16 RC3, TVHeadend HTSP Client 2.2.13, Windows 7. Also tested on android 4.4, s89-H.
I posted also here in Kodi forum: http://forum.kodi.tv/showthread.php?tid=249463&pid=2244389#pid2244389
I still have the "WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available" in my Kodi logs and Kodi stops playback.
In case of starting a recording and playing it back and FF to the end, the playback stops and I return to the menu. In case of pausing live tv, then play and FF the screen freezes and I have to stop it, start it again to watch tv.
This https://github.com/kodi-pvr/pvr.hts/pull/155 seems to suggest the problem is solved. But I'm having the above issue.
The suggestion in this thread is no solution for me: http://forum.kodi.tv/showthread.php?tid=219288&pid=2020772#pid2020772
Can anyone tell me what's the status of the problem? Is it solved, but not yet implemented in Kodi? Do I have to wait for a new release? Or can I download a new pvr.hts somewhere?
Thanks,
Wim
Updated by Wim K almost 9 years ago
Tested on Kodi 14.2, same problem. Kodi log has errors like these below and then stops playback:
ERROR: CDVDPlayerAudio::DecodeFrame - Decode Error. Skipping audio packet (-1094995529)
WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
WARNING: Previous line repeats 1 times.
Can anyone tell me what's the status of this problem? Are the developers working on it or is it marked as solved?
Wim
Updated by Jaroslav Kysela almost 9 years ago
I doubt that the fixes are in 16 RC3. You should wait or compile latest pvr.hts yourself.
Updated by Wim K almost 9 years ago
Jaroslav Kysela wrote:
I doubt that the fixes are in 16 RC3. You should wait or compile latest pvr.hts yourself.
Well, my ptoblem exists in 16RC3. Does that mean the the problem is known and the developers have made a solution for it, but it's just not implemented in Kodi (from kodi.tv download) yet? Any idea in what Kodi version the fix will be implemented?
I don't know how to compile, would take me too much time to learn too
Updated by Jaroslav Kysela almost 9 years ago
I think that it will be in next RC / final, but it would be better to ask on IRC or directly for pvr.hts plugin: https://github.com/kodi-pvr/pvr.hts/issues
Updated by Wim K over 8 years ago
Jaroslav Kysela wrote:
I think that it will be in next RC / final, but it would be better to ask on IRC or directly for pvr.hts plugin: https://github.com/kodi-pvr/pvr.hts/issues
Hi Jaroslav,
I've been looking at the link you posted and under "closed" I saw "Timeshift #144" from "perexg" (same picture, is it you?).
I understand it is closed. I also read:
"Timeshift: Seeking fixes #155 Merged
[PVR] Addon API 5.0.0 xbmc/xbmc#8736 merged"
So I assume it's ready to be implemented in pvr.hts. I've installed Kodi 16 Final, but pvr.hts seems to be the same release as I used in RC3.
I don't understand what's the proper way to ask. I thought maybe there's an overview somewhere. I don't want to bother people with questions that I am supposed to know.
MAybe there's a way to update a new pvr.hts myself without having to wait for an update from Kodi, but I don't know how to do that.
So for a layman like me, how can I tell when there will be a new release of pvr.hts (that can be updated in Kodi) and what issues will be resolved in that version and what issues are still not resolved in pvr.hts that is installed in Kodi.
Thanks,
Wim
Updated by Meindert Oldenburger over 8 years ago
I have Kodi 16.0 with PVR plugin 2.2.14. All seems to work fine.
My system is Debian and Kodi with plugin is installed from deb-multimedia.org
Updated by Meindert Oldenburger over 8 years ago
Meindert Oldenburger wrote:
I have Kodi 16.0 with PVR plugin 2.2.14. All seems to work fine.
My system is Debian and Kodi with plugin is installed from deb-multimedia.org
And TVHeadend version: 4.1-1566
Updated by Wim K over 8 years ago
On my windows laptop I have Kodi 16.1, pvr.hts 2.2.14 and tvheadend_4.1-1723~g465f64c_armhf (so latest of everything).
This is what I do in Kodi: I watch a channel and press "record". Then I press stop.
Then I playback the recording and FF (or skip) to the end of the buffer.
Then Kodi STOPS playback.
(This is different from watching livetv, pausing and FF to end of buffer!!! That works although I would prefer TVHeadend to stop FF and start PLAY instead of trying to keep on FF-ing)
In the Kodi logs I see that Kodi stops receiving data and therefore stops playback.
I have tried logging in tvheadend but probably I'm doing it wrong because I can't see much info about the file being sent to Kodi. So I don't know what tvheadend is doing.
Please help.
Wim
Updated by Jaroslav Kysela over 8 years ago
Wim K wrote:
On my windows laptop I have Kodi 16.1, pvr.hts 2.2.14 and tvheadend_4.1-1723~g465f64c_armhf (so latest of everything).
This is what I do in Kodi: I watch a channel and press "record". Then I press stop.
Then I playback the recording and FF (or skip) to the end of the buffer.
Then Kodi STOPS playback.(This is different from watching livetv, pausing and FF to end of buffer!!! That works although I would prefer TVHeadend to stop FF and start PLAY instead of trying to keep on FF-ing)
In the Kodi logs I see that Kodi stops receiving data and therefore stops playback.
I have tried logging in tvheadend but probably I'm doing it wrong because I can't see much info about the file being sent to Kodi. So I don't know what tvheadend is doing.
You should report this here: https://github.com/kodi-pvr/pvr.hts/issues , tvheadend cannot predict what the client expects. I think that when the end-of-file state reaches, the kodi/pvr.hts stops playback (no more data) and there's no switch to live-tv. But basically, playback of recordings and timeshift in the live-tv are two different things, so you should stay in the live-tv (with pause/timeshift) and do FF in live-tv (timeshift).
Updated by Wim K over 8 years ago
Jaroslav Kysela wrote:
Wim K wrote:
On my windows laptop I have Kodi 16.1, pvr.hts 2.2.14 and tvheadend_4.1-1723~g465f64c_armhf (so latest of everything).
This is what I do in Kodi: I watch a channel and press "record". Then I press stop.
Then I playback the recording and FF (or skip) to the end of the buffer.
Then Kodi STOPS playback.(This is different from watching livetv, pausing and FF to end of buffer!!! That works although I would prefer TVHeadend to stop FF and start PLAY instead of trying to keep on FF-ing)
In the Kodi logs I see that Kodi stops receiving data and therefore stops playback.
I have tried logging in tvheadend but probably I'm doing it wrong because I can't see much info about the file being sent to Kodi. So I don't know what tvheadend is doing.You should report this here: https://github.com/kodi-pvr/pvr.hts/issues , tvheadend cannot predict what the client expects. I think that when the end-of-file state reaches, the kodi/pvr.hts stops playback (no more data) and there's no switch to live-tv. But basically, playback of recordings and timeshift in the live-tv are two different things, so you should stay in the live-tv (with pause/timeshift) and do FF in live-tv (timeshift).
Yes, I've come to the same conclusion, that livetv-pausing (timeshifting) is different than watching a recording "time-shifted".
The first works correct, the latter doesn't. We often watch a recording 15 minutes after it has started. When the end-of-file state is reached, it would be really awesome if TVHeadend than tells Kodi (or the player TVHClient uses) to stop FF (or skip) and "play" live.
Thanks for the response.
Wim
Updated by Wim K over 8 years ago
@Jaroslav Kysela:
This is related to watching "timeshifted", although not directly to my issue above
but I didn't know where else to post this question to you:
I saw your post:
https://github.com/kodi-pvr/pvr.hts/issues/144
My question is: is it not possible to fix this from within tvheadend? Because this problem also exists when using tvhclient in combination with mxplayer.
Or does the developer of tvhclient has to fix it? I mean is tvheadend already able of handling it in combination with mxplayer?
Updated by Wim K over 8 years ago
@Jaroslav Kysela:
As you proposed, I posted my issue in github.
I suggested that playing back a recording-in-progress could perhaps be interpreted as a request to playing live-tv. In that case my problem (Kodi stopping playback whilst it doesn't when the file is "live-tv") is solved.
Out of curiosity: Why is the streaming of the file not stopped at EOF when it's "live-tv" and it is when it's a recording (also when it's a recording of live-tv)? They are both files. What's the difference and what program tells it to keep on streaming even at EOF when it's live-tv?
Jalle 19 wrote that that could be possible, but that would need to be done in Kodi, not pvr.hts.
What do you think as TVHeadend developer? Should it be solved in pvr.hts or in Kodi?
Or even in TVHeadend?? Because the problem also exists when using TVHClient together with mxplayer.
Wim