support for local server

[clausmuus]

I think it has enough power. the VDR needs only 10% CPU and the vompclient, as you know, needs 50 - 60% power. That should not the reason.
Thins I know nearly nothing about the vomp, its protocol and how it works, I have no idea how I should detect the reason for the connection problem. It's more than 20 years ago, that I really programed in c++ last time.

So it will really great if you or a other people can try to find the reason and fix it.

@ the people who like try to fix it,
For testing this, it is not necessary to have a DVB-Stick connected to the RPI. It's also possible to use the streamdev-client VDR plugin, with the same effect. Beside this, e.g. the dummydevice plugin is needed and if you want to have a VDR frontend e.g. the skincurses plugin.

Claus

[clausmuus]

I have a little more information about this problem. If I select a channel, that cant be tune (because the signal is to low), the connection don't lost. If I tune a well channel, first the frontend froze for 5 seconds and then I get the message "Connection lost". In this state I can only restart the vompclient. It don't accept any key press (e.g. to select the OK button).

Claus

[MartenR]

Another thing is that vompclient is really memory hungry.

The sympton you are describing, means it has something to do with starting a streaming channel which are handled as special streaming channel.
Anyway debugging will be done by putting log messsage to the VDR class and tracing back were the lost connection appears.
I have in the moment no time to debug this, first the porting client has to be finished and then I might have to reduce the time I spent into vomp and this problem sounds like it takes days to debug, including setting up a local vdr. Anway I will assist everyone, who wants to debug this.

Marten

[clausmuus]

Hi,

I fond a solution for this. A friend of mine has had the correct idea. The Problem is the MTU size of the loopback device. Default of this is 16436 and the default of eth0 is 1500. After I change the MTU size of the loopback to 1500 I can also use a local vdr server.
Do you have any idea what is the reason for the problems with a big MTU? And do you can fix this in the vomp-client/server?

Claus

[MartenR]

No I have no idea, maybe some socket options has to be set.

[MartenR]

Well, the standard idea, play with the tcp window size....

[clausmuus]

I have set the tcpWindowSitze (if this it what I can set in the configurations menu) to 4096, but the first stream package (over loopback) has a sitze of 16kB.

Claus

[MartenR]

Well, they do not have to match, but anyway you should just try different settings.

[Chris]

Hi.

To answer a question much earlier in the thread, the upcoming release of version 0.4.0 will support locating a VDR/VOMP server on the same IP as the client.

[JTe]

Could it be possible to change the upcoming server version 0.4.0 the way that the subtitle and audio pids are organized on server side using the preferred order of audio and subtitle channels of VDR? This way the vomp client would always play correct audio channel. For subtitles an option to display subtitles by default could be then added and the subtitles would also be in correct language.

Currently the pids are in order they are broadcasted and for example if I prefer French language over German the Arte channel (which has the German audio pid before French) will be in German and I have to always select the French audio track manually.

[TVIA]

Hi Chris,

To answer a question much earlier in the thread, the upcoming release of version 0.4.0 will support locating a VDR/VOMP server on the same IP as the client.

I tune a well channel, after 2-3 seconds and then I get the message "Connection lost" ?

- I use the version 0.4.1-dev on raspbian last version.
- I connect via vlan eth0.2 with the tuner of the NetCeiver
- VDR-1.7.28 with dummydevice-, vompserver- and mcli-plugin

Code Select Expand

top - 21:27:00 up 5 min,  1 user,  load average: 0,79, 0,77, 0,38
Tasks:  65 total,   1 running,  64 sleeping,   0 stopped,   0 zombie
%Cpu(s): 14,1 us, 19,5 sy,  2,1 ni, 53,9 id,  0,0 wa,  0,0 hi, 10,4 si,  0,0 st
KiB Mem:    314664 total,   198928 used,   115736 free,    12844 buffers
KiB Swap:   262140 total,        0 used,   262140 free,    83584 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                   
2610 vdr       20   0  279m  50m 4608 S  27,6 16,5   1:40.19 vdr                                                                       
2678 root      20   0  186m  32m 5520 S  13,3 10,6   0:49.68 vompclient                                                               
2867 root      20   0  5172 1364 1020 R   1,3  0,4   0:00.96 top                                                                       
    3 root      20   0     0    0    0 S   0,3  0,0   0:00.38 ksoftirqd/0

ifconfig

Code Select Expand

eth0      Link encap:Ethernet  Hardware Adresse 70:71:bc:09:44:b6 
          inet Adresse:192.168.1.21  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::7271:bcff:fe09:44b6/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:13424958 errors:0 dropped:0 overruns:0 frame:0
          TX packets:95775 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:2896449962 (2.8 GB)  TX bytes:14730025 (14.7 MB)
          Interrupt:44

eth0.2    Link encap:Ethernet  Hardware Adresse 70:71:bc:09:44:b6 
          inet6-Adresse: fe80::7271:bcff:fe09:44b6/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:13410992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:72492 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:11241801073 (11.2 GB)  TX bytes:11835828 (11.8 MB)

lo        Link encap:Lokale Schleife 
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:1500  Metrik:1
          RX packets:7651 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7651 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:51364131 (51.3 MB)  TX bytes:51364131 (51.3 MB)

vompserver.log

Code Select Expand

21:34:15.084802 [debug]  RRProc - Using live TV priority 0
21:34:15.190882 [debug]  MVPReceiver - VDR active
21:34:15.221876 [debug]  MVPReceiver - num mvp receivers now up to 1
21:34:15.222380 [debug]  RRProc - threadMethod waiting
21:34:15.224292 [debug]  Client - Received chan=3 kats=1368473655
21:34:15.225203 [debug]  Client - Waiting
21:34:17.592120 [debug]  Client - Vomp client destructor
21:34:17.593014 [debug]  MVPReceiver - VDR inactive, sending stream end message
21:34:17.595876 [debug]  MVPReceiver - num mvp receivers now down to 0
21:34:17.604690 [debug]  TCP - TCP has closed socket
21:34:17.609048 [info]   RRProc - threadMethod err 2 or quit
21:34:25.900251 [debug]  RRProc - get schedule called for channel 2
21:34:25.900431 [debug]  Client - Looking for channel 2::: number: 1 name: 'Das Erste HD'
21:34:25.901256 [debug]  Client - Looking for channel 2::: number: 2 name: 'ZDF HD'
21:34:25.901399 [debug]  Client - Found channel number 2, vpid = 6110, apid1 = 6120
21:34:25.901511 [debug]  RRProc - Got channel
21:34:25.901618 [debug]  RRProc - Got schedule!s! object
21:34:25.901755 [debug]  RRProc - Got schedule object
21:34:25.906215 [debug]  RRProc - Got all event data
21:34:25.912550 [debug]  RRProc - written schedules packet
21:34:25.912822 [debug]  RRProc - threadMethod waiting
21:34:56.873357 [debug]  Client - Waiting
21:34:56.873541 [debug]  RRProc - thread woken with req, queue size: 1
21:34:56.873675 [debug]  RRProc - thread while
21:34:56.873808 [debug]  RRProc - received command 12
21:34:56.874255 [debug]  RRProc - Written config load packet
21:34:56.880514 [debug]  Client - Received chan=1, ser=1371, op=11, edl=28
21:34:56.881207 [debug]  RRProc - recvReq
21:34:56.881362 [debug]  RRProc - recvReq set req and signalled
21:34:56.881634 [debug]  Client - Waiting
21:34:56.882830 [debug]  RRProc - thread while
21:34:56.883009 [debug]  RRProc - received command 11
21:34:56.883127 [debug]  RRProc - Config save: General Last Power State On
21:34:56.904619 [debug]  RRProc - threadMethod waiting
21:35:04.906588 [debug]  Client - Received chan=3 kats=1368473702
21:35:04.908199 [debug]  Client - Waiting
21:35:10.912365 [debug]  Client - Received chan=3 kats=1368473708
21:35:10.913047 [debug]  Client - Waiting


vdr-err.x

Code Select Expand

Discontinuity on receiver 0x4547a70 for pid 5101: 2->9 at pos 0/7
Discontinuity on receiver 0x4547a70 for pid 5101: 6->0 at pos 0/7
Discontinuity on receiver 0x4547a70 for pid 5101: 15->7 at pos 0/7
Discontinuity on receiver 0x4547a70 for pid 5101: 11->3 at pos 0/7

Do you have any idea how I could solve the problem "Connection lost"?

tvia

[TVIA]

hi,

no idea?

tvia