Messages

Reverting back to all stable packages fixed the crash. I had tested the rpihddevice with vdr on the rpi a while ago and was getting the 2.x vdr packages from jessie. Once I reverted back to all rasbian squeeze stable all works fine.

Sorry for the poor testing from my part :-( - I should know better...

Will put it under more stress during the rest of the holidays. But it is looking fine so far.

Subtitles are embedded in the stream i.e. burned into the stream. The subtitles are NOT according to ETSI EN 300 743!

I have turned off all audio and language preferences in vdd's setup.conf but the segfault still occurs.
Reverted commit de6fbe2d494aac80e0be1051f06ad72ad6718473 without improving the issue.
Commit 89d00b9f8d3e3b5a3deeb87b6f6aafd6ec11c7ca does not revert cleanly so I did not try that out. Tried the commits around the commit 89d00b9f but they did not compile cleanly :-(

I have uploaded a short recording, around 50MB, to google drive that gives the segfault for me.
https://drive.google.com/file/d/0B4LQIJR9gOUmUzFrWGRpQ3pNMDQ/view?usp=sharing

As per the question if there are subtitles? Yes the recording has Swedish subtitles. As far as I know the subtitles are part of the stream and cannot be disabled. I hardly ever use any other fronted than vompclient to vdr so I'm pretty unfamiliar with any possibility to turn off subtitles.

Well, you can hit the green button and select no subtitles, then the subtitle content is ignored by vomp. Or are your subtitles part of the video stream?
Anyway your debug trace shows clearly, that the crash happens inside the subtitle decoder. I expect something with now using the default vdr setting for subtitles, which turns your subtitles on.
(Does the crash occur at every skip? Or how often do I have to try?).
The gdb stuff did not help, since it looks like a currupted stack.
I tried to reproduce it, but I failed. Can you please prepare do the following:
1) Tell me your default setting for languages and subtitles on vdr side?
2) Report the selected tracks, if you hit the green button.
3) Deapply patch from http://git.vomp.tv/gitweb/?p=vompclient.git;a=commitdiff;h=de6fbe2d494aac80e0be1051f06ad72ad6718473 and http://git.vomp.tv/gitweb/?p=vompclient.git;a=commitdiff;h=89d00b9f8d3e3b5a3deeb87b6f6aafd6ec11c7ca, this way we see if it has something to do with the get subtitle settings from vdr patch.
4) Go back to the normal code (without modifications form 3)) and uncomment the line

Code Select Expand

logger->log("VDR", Log::DEBUG, "Langpref %s %d %d", newpref.langcode.c_str(),  newpref.audiopref,  newpref.subtitlepref); in vdr.cc and give me the corresponding log. This way I can see your subtitle settings. (only if 3) does not show a crash)
5) Prepare a short recording for me, which shows the desired crash, so that I can analyze it.

Marten

Yes I did make clean before the build was done. It was compiled as release. I have now recompiled as with debug and the crash is still there.

As per the question if there are subtitles? Yes the recording has Swedish subtitles. As far as I know the subtitles are part of the stream and cannot be disabled. I hardly ever use any other fronted than vompclient to vdr so I'm pretty unfamiliar with any possibility to turn off subtitles.

root@raspberrypi:~/vomp-tvscraper# gdb ./vompclient core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/vomp-tvscraper/vompclient...done.
[New LWP 11659]
[New LWP 11667]
[New LWP 11646]
[New LWP 11670]
[New LWP 11640]
[New LWP 11644]
[New LWP 11669]
[New LWP 11671]
[New LWP 11639]
[New LWP 11642]
[New LWP 11643]
[New LWP 11645]
[New LWP 11655]
[New LWP 11668]
[New LWP 11647]
[New LWP 11638]
[New LWP 11637]
[New LWP 11650]
[New LWP 11649]
[New LWP 11636]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `/root/vomp-tvscraper/vompclient'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fab3c4 in unwind_stop () from /lib/arm-linux-gnueabihf/libpthread.so.0
(gdb) bt
#0  0xb6fab3c4 in unwind_stop () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0xb6049918 in ?? () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
#2  0xb604a64c in _Unwind_ForcedUnwind () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
#3  0xb6fadb88 in _Unwind_ForcedUnwind () from /lib/arm-linux-gnueabihf/libpthread.so.0
#4  0xb6fab424 in __pthread_unwind () from /lib/arm-linux-gnueabihf/libpthread.so.0
#5  0xb6fa50b0 in pthread_exit () from /lib/arm-linux-gnueabihf/libpthread.so.0
#6  0x000cd9b4 in ThreadP::threadCheckExit (this=0x2007e8) at threadp.cc:70
#7  0x000b523c in DVBSubtitles::threadMethod (this=0x2007e8) at dvbsubtitles.cc:962
#8  0x00016a70 in Thread::threadInternalStart2 (this=0x2007e8) at thread.cc:35
#9  0x000cd800 in threadPInternalStart (arg=0x2007e8) at threadp.cc:32
#10 0xb6fa3e90 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#11 0xb5fbc4e8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#12 0xb5fbc4e8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The latest commit r3f2e06e168db1d2580cef98385674f75084c64a0 breaks the raspberry pi builds.
signal.o needs to be listed in objects.mk

I also get a segfault when jumping or fast fwd while watching recordings. 100% reproducible and crashed immediately after pressing e.g. 1-9 or pressing forward/rewind. Crashed on both SD, 1080i and 720p recordings.

Attaching log when a crash occurs.

- Magnus

Did you follow the instructions in my previous post?

http://forum.loggytronic.com/index.php?topic=707.0

If you find anything that is not up to date or plain wrong then please update the instruction.

My server is a gentoo box running vdr 2.0.4,vompserver 0.4.0, epgsearch 1.0.0, streamdev 0.6.1 and some others.

My vompclient is basically built based of the current trunk of the vompclient.git repository with a change of the protocol version in vdr.cc to have the define VOMP_PROTOCOLL_VERSION set to 0x00000200 instead of 0x00000300

With this minor change its possible to use the latest vompclient against a vompserver with version 0.4.0. The reason I have patched the client like this is that there is yet no stable vompserver of version 0.4.1 and I'm to lazy to bother to unmask 0.4.1 from the gentoo repositories.

The vomp-server plugin is installed on the vdr server as any other plugin.
In your case that would be on your existing desktop pc running vdr. It works marvellous well. Have used it for more than a decade streaming to hauppauge media-mvp hardware running a vomp client. Since a year I have turned to HD and is using raspberry pi's as clients running vomp. Its running rock solid since a half year back.

It appears as if the option "16:9 on 4:3 display mode" setting serves dual purposes.

The setting itself suggests that it has to do with how 16:9 resolutions are displayed on a 4:3 TV. It does however appear as if the setting is also used to determine how 4:3 resolutions are displayed on 16:9 TV's.

Perhaps the setting shall be renamed to something more apropriate and that the terminology used for the choices are adopted to the actual chosen TV aspect ratio. The simplest solution may perhaps be introducing another setting named "4:3 on 16:9 display mode"

E.g. choosing "Chop sides" is not really the re-scaling that is done when a 4:3 picture is rescaled to fit a 16:9 display.

I actually missed the possibility to get 4:3 broadcast's to fill the whole screen due to the nomenclature used.

I got kind of the same results prior to commit df256d9401cf168b7e336522f6295b1ac91450c0 16:9 SD channels with the "16:9 on 4:3 display mode" set to "Chop sides"

Please check forum thread http://forum.loggytronic.com/index.php?topic=730.0

Hi!

I'm not sure if this is what my RPi is suffering, but in one channel (viisi in finland) picture is cut from top and bottom. So for example it loses subtitles
Whole screen is used, but top and bottom are cut off.
My TV is 16:9 and I'm using HDMI.
Where can I get some helpful log to examine what is happening or to send someone (Marten?) who understands what's happening...
I guess this is something to do with channel provider. As far as I know, this happens only with that one channel (or at least I haven't watched any other channel suffering from this). Maybe they don't provide all information needed... Although VDR shows that channel correctly.

- Samuli

Thanks Marten - That did the trick.

Noticed this behaviour at first while watching some old recordings made in SD but can confirm that its the case while watching live tv as well.

Our tv's are all 16:9 tv's and the vompclient settings are:
[TV]
Widemode = Letterbox
Aspect = 16:9

16:9 HD (720p and 1080i) channels fill the whole tv screen as one would expect but SD channels show something that is more like a 4:3 ratio with big black bars on the sides. If the Wideomode is changed to "Chop Sides" the picture fill the complete tv screen but with a huge overscan. This behaviour is seen on both 704x576i and 720x576i broadcasts.

I have attached a log file where I start out watching a channel in HD (1280x720) resolution and then switching to the same channel in SD (704x576). Note that this is a slightly modified vompclient where I print out the reason for failures in the mp3 audio decoding. It is what I use while troubleshooting the audio chirps described in other posts.

Noteworthy is that the log entry where the VideoType is shown says:
15:30:17.836841 [notice] 2079 Video - VideoType 148 x 2001 i: 1
after the switch. If one choose the channel from the channel list instead one get the correct printout of VideoType 704 x 576!

The same wrong log entry has also been observed while switching from an SD channel to an HD channel. Below is some channel switches made grep'ing only VideoType. Observe the weird resolution 14x480 (Should really be 1280x720).

20:17:32.143785 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:17:38.653976 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:17:44.114826 [notice] 2314 Video - VideoType 1920 x 1080 i: 1
20:18:02.565919 [notice] 2314 Video - VideoType 1920 x 1080 i: 1
20:19:36.850602 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:20:14.184033 [notice] 2314 Video - VideoType 14 x 480 i: 1
20:20:44.583299 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:20:52.330869 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:21:21.655706 [notice] 2314 Video - VideoType 1920 x 1080 i: 1
20:21:59.436071 [notice] 2314 Video - VideoType 720 x 576 i: 1
20:22:24.227793 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:22:31.549092 [notice] 2314 Video - VideoType 720 x 576 i: 1
20:22:36.798217 [notice] 2314 Video - VideoType 720 x 576 i: 1
20:22:47.891242 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:22:54.617073 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:23:16.594869 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:27:06.148200 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:29:50.728992 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:30:07.083192 [notice] 2314 Video - VideoType 704 x 576 i: 1
20:30:33.556668 [notice] 2314 Video - VideoType 1280 x 720 i: 0
20:31:10.611470 [notice] 2314 Video - VideoType 1280 x 720 i: 0

@winschrott
Below is a link to a small, 35MB, recording with an audible audio chirp about 5 seconds into the recording. I hope the recording is not too small.

https://drive.google.com/file/d/0B4LQIJR9gOUmV2hQVEgySWVVX1U/edit?usp=sharing


The clip is from SVT2 HD - A 720p public service channel broadcasted in Sweden. The format of the channel is as mentioned previous in this thread.

The specs of the channels are http://www.svt.se/omsvt/om-sandningarna/hdtv/expertinformation:
Video
H.264/AVC/MPEG-4 Part 10 with variable BitRate (VBR). Practically this means that the bitrate may vary between 4 and 16 Mbit/s.

Audio
Both stereo and 5.1 multichannel. The 5.1 sound is coded as Dolby Digital (AC3) @ 448 kbit/s. The stereo sound is coded as MPEG1-L2@256kbit/s

The recording does not give any audio chirp when played using the rpihddevice.

I have briefly for a few hours tested the latest git commit and there are occasionally frames with reserved version id detected. Not many at all but perhaps a few per ten minutes during my tests.

Did as well test with the increased accuracy of ending the loop but cannot yet tell if that improves things or not.

What really made it possible for us to go into "production" with the vompclient pi's was the header continuity check. Please don't remove that. Tested without it (but with the reserved version id check) and got the nasty audio chirps back on our 720p channels.

- Magnus

That is definitely due to using an "unsupported" version of libcec.

More information here:
http://forum.loggytronic.com/index.php?topic=692.msg4088#msg4088

- Magnus

>Can you please clarify your comment to 2).
>I am a bit confused. So without the CEC_OPCODE_STANDBY handler,
>everything works as in 1)? Do you have also the problem with the remote?

It worked exactly as in comment 1). I.e. when the TV was awakened from standby the remote commands would not be passed on to the pi. One had to pick the source once again from the "Choose input source" menu on the tv to get the client registered with the TV.

I have tested with the latest commit, 30e68c9d03d1075463adcd28ca1a79e0ad8ea00f, and now it works perfectly again. One does not even have to do the switch input source thing to get remote commands passed to vompclient after the TV has been suspended. Thanks.

I will make some tests on another Philips TV as well and on two different Samsung models to see if it behaves correctly on those as well.