Tvheadend

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?

no I cant confirme this. the bug is in 3.9.2662 still present

Thanks for the reply.

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

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

I don't know why the lines above are cancelled but they should NOT.

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

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.

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.

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] tvheadend¹¹⁶⁸: 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] tvheadend¹³⁹⁷: 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] tvheadend¹⁴¹⁷: 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] tvheadend¹⁴³²: 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] tvheadend¹⁴⁴⁷: 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] tvheadend¹⁴⁶²: 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] tvheadend¹⁴⁷⁷: 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] tvheadend¹⁴⁹²: 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] tvheadend¹⁵⁰⁷: 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] tvheadend¹⁵²²: 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?

Could you run tvheadend in terminal ?

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.

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

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).

Hi Jaroslav,

your code changes seem to improve stability at least. First test were successful. I'll do some extended testing next weekend.

Thanks!

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.

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).

Fixes for pvr.hts: https://github.com/kodi-pvr/pvr.hts/pull/146

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.

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... ;)

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.

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

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 ...

@Manfred Kreisl: I rebased my changes in PR #155. You must not call SendSpeed() in the last patch block.

I do testing with kodi 15.2 and code from PR #146 . I'm not able to crash TVH with this combo and seeking in kodi looks very solid. Share crashes.

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.

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))

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!

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

Pushed many timeshift fixes to v4.1-1294-ga1b7002 . The packet clocks should be ok now with the maintaining of coherency (server-client) now.

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 :)

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.

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 :).

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?

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.

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 :)

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.

v4.1-1303-gbd69326 - rewind / fast-forward more 'interactive'.. Nearly perfect timeshift now...

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 :)

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.

Now testing 1303:

SD channels seems ok, 1080i channels seems ok BUT: 720p channels are mostly unusable

• 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)

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

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) 

@Manfred: Enable the verbose debug log in pvr.hts plugin to see the incoming packets for 720p. Also "--trace timeshift" (tvh) might uncover something.

I already had trace of timeshift enabled. But this floods log extremely so I stopped using this.

So, had success in logging error:

TVH log
Kodi log

Just starting channel, after some seconds playing stopped. During this time, doing nothing on the client

Hopefully this logs helps finding the issue

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?)

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.

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

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.

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.

With 4.1-1333~g196b1d9 theese kind of artifacts has been gone :)

Timeshift is now usable

Thanks

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

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

I doubt that the fixes are in 16 RC3. You should wait or compile latest pvr.hts yourself.

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 :(

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

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

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

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

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

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).

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

@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?

@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