gkovacsp:
uploaded logs:
You need to enable debug logging otherwise not much to see.
Suggest to enable debug logging, reboot, play channel, upload logs via SSH
Sorry, I thought logging was enabled.
Here it is again: http://paste.osmc.io/uhejoqodeh
Gabor
I have a link to try the stream: http://-/t/tvheadend/stream/channel/a4e1841d2f8040302241e6e4300ce4d9?ticket=87E6E340872A4CBCE871F0AFAF406C5E70102FBC
Nothing that I can see in the log that would explain it. Maybe someone else can see something.
@gkovacsp the url you posted requests a password so I can’t test it.
Are you able to record from the problematic channel and cause the same crash? If so then a sample file would be useful.
A recorded file does not crash.
Please try osmc/osmc as a username/password for the above link.
Thanks!
Here is a link to an example recording: Dropbox - File Deleted
Which unfortunately does not crash.
Is it possible that the channel has too many streams in it (24)? There are many subtitle streams (16-18).
I’ve played around with TVHeadend and figured out, that the problem is indeed the large number of Subtitle tracks. If I filter some of them out on the server side, then Kodi will play it nicely.
It is not a problem when recording to a file, because TVHeadend detects that there is no more stream space available and trims some of the subtitle streams.
It will work for me, but I guess this should be fixed in the Kodi player.
Thanks!
How are you able to play this stream through kodi?
I’m not succeeding in specifying the username/password, either through adding to end of url (&username=kodi&password=kodi) or when adding an IPTV network to tvheadend.
In KODI I use TVHeadend’s PVR client for streaming.
The link I’ve given to you works from VLC
In case you have the PVR add-on installed I can share the TV server with you in a PM.
The crash is in the pvr.hts addon, so not caused by kodi or osmc.
I did some minimal debugging and created an issue here:
opened 06:56PM - 02 Jan 17 UTC
closed 12:55PM - 05 Jan 17 UTC
Bug
I was looking into crash reported here:
https://discourse.osmc.tv/t/tv-channel-… crashes/21206/15
I think this is the key bit of info:
> Is it possible that the channel has too many streams in it (24)? There are many subtitle streams (16-18).
I've played around with TVHeadend and figured out, that the problem is indeed the large number of Subtitle tracks. If I filter some of them out on the server side, then Kodi will play it nicely.
It is not a problem when recording to a file, because TVHeadend detects that there is no more stream space available and trims some of the subtitle streams.
I can reproduce issue and crash occurs in pvr.hts (built from current master of this repo):
```Program terminated with signal SIGSEGV, Segmentation fault.
#0 _M_lower_bound (this=<optimized out>, __k=@0x619feba0: 94210, __y=0xee2b5a06, __x=<optimized out>)
at /home/dc4/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/include/c++/4.9.3/bits/stl_tree.h:1261
1261 /home/dc4/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/include/c++/4.9.3/bits/stl_tree.h: No such file or directory.
(gdb) bt
#0 _M_lower_bound (this=<optimized out>, __k=@0x619feba0: 94210, __y=0xee2b5a06, __x=<optimized out>)
at /home/dc4/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/include/c++/4.9.3/bits/stl_tree.h:1261
#1 lower_bound (__k=@0x619feba0: 94210, this=0x7460bb0c) at /home/dc4/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/include/c++/4.9.3/bits/stl_tree.h:927
#2 lower_bound (__x=@0x619feba0: 94210, this=0x7460bb0c) at /home/dc4/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/include/c++/4.9.3/bits/stl_map.h:902
#3 operator[] (__k=<unknown type in /opt/xbmc-cmake/arm-linux-gnueabihf/lib/kodi/addons/pvr.hts/pvr.hts.so.4.0.1, CU 0x3a553, DIE 0x54955>, this=0x7460bb0c)
at /home/dc4/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/include/c++/4.9.3/bits/stl_map.h:516
#4 CHTSPDemuxer::ParseSubscriptionStart (this=this@entry=0x7460b5b0, m=0x17002, m@entry=0x68416880) at /home/dc4/xbmc_holder/pvr.hts/src/HTSPDemuxer.cpp:456
#5 0x70832e50 in CHTSPDemuxer::ProcessMessage (this=this@entry=0x7460b5b0, method=method@entry=0x67332980 "subscriptionStart", m=m@entry=0x68416880)
at /home/dc4/xbmc_holder/pvr.hts/src/HTSPDemuxer.cpp:336
#6 0x7083a0b4 in CTvheadend::ProcessMessage (this=<optimized out>, method=method@entry=0x67332980 "subscriptionStart", msg=msg@entry=0x68416880) at /home/dc4/xbmc_holder/pvr.hts/src/Tvheadend.cpp:1406
#7 0x70827bc8 in CHTSPConnection::ReadMessage (this=0x92c, this@entry=0x74603c18) at /home/dc4/xbmc_holder/pvr.hts/src/HTSPConnection.cpp:324
#8 0x708291f4 in CHTSPConnection::Process (this=0x74603c18) at /home/dc4/xbmc_holder/pvr.hts/src/HTSPConnection.cpp:650
#9 0x7082cf44 in P8PLATFORM::CThread::ThreadHandler (_thread=0x74603c18) at /opt/xbmc-cmake/arm-linux-gnueabihf/include/p8-platform/threads/threads.h:65
#10 0x76dd4e90 in start_thread (arg=0x619ff410) at pthread_create.c:311
```
(this is the line m_streamStat[idx] = 0;)
I added some logging to see how far it gets: http://paste.ubuntu.com/23729089/
```
Abort0: 0/0/178956970
ParseSubscriptionStart: clear: 0/0/178956970
ParseSubscriptionStart: zero: 2/0/178956970
ParseSubscriptionStart: zero: 1/1/178956970
ParseSubscriptionStart: zero: 3/2/178956970
ParseSubscriptionStart: zero: 4/3/178956970
ParseSubscriptionStart: zero: 5/4/178956970
ParseSubscriptionStart: zero: 6/5/178956970
ParseSubscriptionStart: zero: 7/6/178956970
ParseSubscriptionStart: zero: 8/7/178956970
ParseSubscriptionStart: zero: 9/8/178956970
ParseSubscriptionStart: zero: 10/9/178956970
ParseSubscriptionStart: zero: 11/10/178956970
ParseSubscriptionStart: zero: 12/11/178956970
ParseSubscriptionStart: zero: 13/12/178956970
ParseSubscriptionStart: zero: 14/13/178956970
ParseSubscriptionStart: zero: 15/14/178956970
ParseSubscriptionStart: zero: 16/15/178956970
ParseSubscriptionStart: zero: 17/16/178956970
ParseSubscriptionStart: zero: 18/17/178956970
ParseSubscriptionStart: zero: 19/18/178956970
ParseSubscriptionStart: zero: 20/19/178956970
ParseSubscriptionStart: zero: 21/20/178956970
ParseSubscriptionStart: zero: 22/0/178956970
```
It feels like there is some limit of around 20 streams before memory gets corrupted.
This isn’t code I know about, so that’s probably as far as I can go, but hopefully a pvr.hts maintainer will be able to do something with the info provided.
Just noticed… If you are running a Pi3, are you aware that you are underclocking the CPU?
arm_freq=1000
core_freq=500
over_voltage=2
sdram_freq=500
That’s a great catch, thanks!
Now this is interesting.
I’ve used OSMC to overclock it, I’ve selected the Turbo mode on the interface, but Turbo sets it to 1000 Hz.
It seems it thinks my RPi is an older version. Is that possible?
Just set it to normal and then reboot. MyOSMC is not yet optimized for pi3 overclocking.
That did the trick. Thanks!
@sam_nazarko Fixes have been merged to kodi (inc Krypton branch) and pvr.hts add-on.
@gkovacsp Thanks for help in reproducing the issue. Hopefully the next Krypton build will fix this.