I have a TVheadend server on a different raspberry pi, it has about 100 TV channels.
All of them but one plays nicely on OSMC, this one crashes immediately after tuning into it.
If I watch that channel from VLC or other app (PC and Mac as well) it plays nicely.
How can I track down the problem? Which logs would help?
I’m running the latest OSMC + Kodi 17.0 combo on a Raspberry PI 3b.
Thanks for the help.
This is shown in kodi.log:
12:24:46.335 T:1958454192 NOTICE: VideoPlayer: Opening: pvr://channels/tv/Minden csatorna/pvr.hts_495247780.pvr
12:24:46.336 T:1958454192 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED
12:24:46.338 T:1410593776 NOTICE: Creating InputStream
12:24:46.505 T:1410593776 NOTICE: Creating Demuxer
Suggest first to enable debug logging. Other than that figure out which codec that the channel is using.
Sorry, I forgot to post the link for the uploaded logs: http://paste.osmc.io/rogumaqawa
It seems to use the very same codec as all other similar channels except for one thing: it has a Mono Audio channel.
Could that be the problem?
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!