Messages

Hello,

sorry for my late response. The error is the following:

*** Plugin vompserver:
( if [ -f .standalone ] ; then ( rm -f .standalone; make clean ; make objects ) ; else exit 0 ;fi )
CC vompserver.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"vompserver"' -D__STL_CONFIG_H -DVOMPSERVER -I/home/administrator/vdr-2.2.0/include  -o vompserver.o vompserver.c
CC dsock.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"vompserver"' -D__STL_CONFIG_H -DVOMPSERVER -I/home/administrator/vdr-2.2.0/include  -o dsock.o dsock.c
CC dsock6.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"vompserver"' -D__STL_CONFIG_H -DVOMPSERVER -I/home/administrator/vdr-2.2.0/include  -o dsock6.o dsock6.c
dsock6.c: In member function 'bool DatagramSocket6::init(USHORT)':
dsock6.c:110:3: warning: 'auto' changes meaning in C++11; please remove it [-Wc++0x-compat]
   auto last = std::unique(mcastIndexes.begin(), mcastIndexes.end());
   ^
dsock6.c:110:8: error: 'last' does not name a type
   auto last = std::unique(mcastIndexes.begin(), mcastIndexes.end());
        ^
dsock6.c:111:22: error: 'last' was not declared in this scope
   mcastIndexes.erase(last, mcastIndexes.end());
                      ^
dsock6.c:114:7: warning: 'auto' changes meaning in C++11; please remove it [-Wc++0x-compat]
   for(auto mif : mcastIndexes)
       ^
dsock6.c:114:12: error: 'mif' does not name a type
   for(auto mif : mcastIndexes)
            ^
In file included from /usr/include/x86_64-linux-gnu/sys/select.h:30:0,
                 from /usr/include/x86_64-linux-gnu/sys/types.h:219,
                 from /usr/include/stdlib.h:314,
                 from dsock6.c:21:
dsock6.c:129:3: error: expected ';' before 'do'
   FD_ZERO(&readfds);
   ^
dsock6.c:129:3: error: expected primary-expression before 'do'
dsock6.c:129:3: error: expected ';' before 'do'
dsock6.c:129:3: error: expected primary-expression before 'do'
dsock6.c:129:3: error: expected ')' before 'do'
make[1]: *** [dsock6.o] Fehler 1

Thanks

Hello noone,

do you have the same problem with client 0.5.0 and later with the TV starting again after powering off when the RPI is connected via HDMI / CEC?
I didn´t have this problem since client 0.4.x, but when I introduced the newer ones I got it. No change between hand-made image or the actual client-image. I tried the hdmi-ignore-cec-init-paramter without any change.

Thanks,
winschrott

Hello Chris,
hello Marten,

as in the earlier version of the RPI-Client (0.5.0) I have the same problem on my TV with the actual client-image:

But I found the following problems with the current git:

TV is restarting after power-off when connected by CEC and switched to the HDMI of RasPi (Panasonic TV / RasPi 3 with current firmware, 'hdmi_ignore_cec_init=1' in config.txt set so TV does not turn on when raspi starts).

Positive:
The client seems to be more stable and has a longer timeout if the stream does not start immedeatly after program change (for example because of slow CW in connection with dvbapi). So the client does not get a connection lost.

Thans for your development!

-winschrott

Thanks

Hello,
I tried to compile the actual server 0.5.1 from GIT against VDR 2.2.0. I get errors in dsock6.c - is it because I do not have IPv6 installed on my VDR?

Workaround:
I changed the max. VOMP PROTOCOL VERSION in vompcientrrproc.c to 0x00000500.

CU

In addition to my earlier post:

The TV switches on just at the moment the green LED turns off. In the debug-dump this is at about 21:04:18:035300.

-winschrott

Hello Chris,
hello MartenR,

I use this wonderful client since many years together with yavdr. After a couple of years I changed my current installation with v0.4.1 to the current v0.5 from git and I´m very happy about the current improvements:

- very fast listing/starting playback of recordings (big subvolume mounted via smb) which took ~15sek in earlier versions
- no problems with HD+-channels in addition to current vdr 2.2.0
- new skin

But I found the following problems with the current git:

- TV is restarting after power-off when connected by CEC and switched to the HDMI of RasPi (Panasonic TV / RasPi 3 with current firmware, 'hdmi_ignore_cec_init=1' in config.txt set so TV does not turn on when raspi starts)
- litte colored strip of background can be seen if transmitted picture is not over the full screen and no overscan is configured (could be solved by completely black background when playing TV or playback of recordings)
- refresh of info-bar is not complete when display of time changes or a new channel is selected after the info-bar is called -> new time or channel number is display over the old one
- when complied with the current package-hints in one of the older threads, CEC will not run until I install the current cec again (simply by calling 'apt-get install cec-utils') which replaces the older, manually defined cec library

I tried to understand the sources, found the color-definitions to change the background to complete black. But I was not able to find the positions for info-bar and the restarts of my TV... If you would tell me where I should begin with my investigations or if you need some debug-info, plz tell me.

Last thing:
Actually I switched the gpu-mem to 256MB because sometimes I only got a black screen (which I can leave with back-key to the normal tv) when calling the EPG by the blue-key. This is gone since 256MB GPU and a fixed definition of HDMI-parameters to 1920x1080/50p (normal 24" display is connected with a HDMI/DVI-cable).

Over all I´m very happy with vompclient on raspi! Thanks for your work and tell me if I can help you with further development!

-winschrott

@sirwio

I did a lot of tests the last hours and had no more audio chirps. Did you try other vdr-client-software, for example the new raspihddevice?
Could you give me an actual test-file with chirps? Please not too small, no problem if the file is about 100MB or so. The best would be an original TS-file. What channels are affected?

Thanks,

winschrott

Hello Marten,

for me the following changes seem to work:

audioomx.cc, Line 1582ff:

Code Select Expand


while ( size - test >= 3) {
if (data[test]==0xFF && (data[test+1] &0xe0)==0xe0) {  // 11bit frame sync
if ((data[test+1] & 0x18) == 0x08) {test++;continue;}  //sanity check: mpeg version ID 01 -> reserved
//sanity check inspired by libav
...


I will give it to the friend of mine with the same problem and will report later. But it seems good!

Background:
I think the most important change is to ignore data with the reserved mpeg version 01 which is done in line 3 of my code. The other change belongs to the loop which ends some bytes earlier now but should meet the requirements with more accuracy.

Could be possible that line 1641ff

Code Select Expand


if (mp3sameheadercount>4) {
*framesize=frame_size;
return test; // probably FrameSync
} //skip it if the header changes too frequently


will be obsolete with these changes. I will try the next days.

Happy christmas,

winschrott

Hello Marten,

I tried several things, at last I added a line which gives me debug information in case of NOT mp3sameheadercount>1...4
I get several log-entries from this line with no audible dropouts, but sometimes (60%) NOT when my audio is dropping. In this case the log is empty    !? So it should be an other problem here. Will audio packets be dropped at any other position in case of an error?
I will try to up a short file with some audio dropouts...

CU
winschrott

Hello Marten,

I tried to check the TS-file (recording) with several tools. Actual I´m playing with MPEG-2 TS packet analyser (incl. hex-editor). Error-correction should be done before by using the additional forward-error-correction bytes in the stream which is originally 208 bytes long per packet, for example.
The question is where the errors occur. And if it is "only" a packet misdetection - why?

-winschrott
Out now, qualifying now and football in a few minutes ;-)

Hello Marten,

i do not really understand how the original TS-Stream is processed by vomp.
Which part does demuxing of the TS and is it possible to extract the demuxed stream(s) to check them for errors? The original TS-stream seems to be error-free so it is not clear to me why vomp loses sync or detects wrong audio-headers.

A friend of mine (yotom) tries your mp3sameheader-settings...

CU
winschrott

Hello marten,

I will cut one or several chiprs out of the old file.
I will also try the alternative settings you mentioned.

What do you think about the idea I edited to my last message?

CU

Hello marten,

thanks for debugging.
Now there are no chirps anymore but instead of the chirps I get audio-dropouts for about 0.5-1 sec. ´vompclient -d´ does not give any output in case of these dropouts.
Tell me if I can help you with debugging,...

One idea:
You detect the actual bitrate and so on of the audio stream. As I understand you, you are now dropping audio-frames with a mismatching bitrate. Would it be - only for a try - be possible to set the bitrate to the "matching" settings for these frames you detect as mismatching ones and send these manipulated frames to the decoder instead of dropping them? No need to change this in your GIT, you can send me the changed source-file via PM or attach it to a message.

Thanks,
winschrott

Hi Marten,

had this problem, too. With my old TFT connected to the rasp. It was a 17" TFT, 1280x1024. 16:9 came out with black borders top/bottom, 4:3 with black borders all around. In settings, a 4:3-screen was defined. Can test it again if you want,  the old TFT is beside the actual 23" ;-) Both connected through HDMI -> DVI cable...

CU
winschrott

RUNNING,

thanks