Hi,
I have found on http://code.google.com/p/mediastuff/wiki/VompVdrProtocol a description for a modification that make it possible to detect a vomp server automatically, also if it is running on the same machine as the client.
Did you think, that it is possible to add this modification to the vomp client? The reason is, that I run the vomp server also on the RPI.
Claus
No it is not possible to add this modification to the vomp client, because it is a modification on the server side. (I am only working on the client code in the moment)
@Chris, what do you think about this?
Marten
Hi,
since I made some tests with a local running VDR, I must see, that this don't work. I start the vompclient with the option "-s 127.0.0.1". This helps to connect the vompclient to the local VDR, but if I select a TV channel (I can see the channellist and EPG data), the connection lost and the vompclient hang and do no reconnect.
Do you have any idea how I or you can fix this issue.
Claus
Quote... the vompclient hang and do no reconnect.
Which vdr version you're using? There are problems with vdr-1.7.30, vdr-7.1.29 works....
It is possibly the same problem here --> http://forum.loggytronic.com/index.php?topic=637.msg3561#msg3561 (http://forum.loggytronic.com/index.php?topic=637.msg3561#msg3561)
No, I use the vdr-1.7.29 and not the VDR crashes, but the vompclient loose the connection.
You can find here a logfile: http://www.minidvblinux.de/download/vompclient.log.lost
I have selected a channel at 9:40:09
The connection lost at 9:40:30
I have no problem if the vompclient is connected to the same vdr version on a other machine.
Claus
Hi,
I can confirm Claus be problem. It is the message: Connection lost.
btw. Quite enjoy with mld. 8) My setup is dlink-usb hub, Typhoon DVB-T USB2.0 (WT-200U).
I have try to find a solution for this by my self, but without a result. OK, I find a way, to make it possible to find also a local server automatically, by simply use different ports for the client and the server, but this don't helps by the connection lost problem on select a channel.
Do you have any idea what can be the reason for this and how I can fix it? This is at the moment my most important problem.
Claus
I am not sure, it can still be an endian problem....
So you should check if it is a only problem of having the server on a raspberry pi, regardless of the client.
Marten
That's a problem. Since I have only one RPI, I can only test again the same Distry Version (this includes the same VDR and vompserver sources) on a x86, and alternatively the server on the same RPI as the client is running on.
If the server is running on second System (an x86'er) it works well. If the server is running on the same RPI, I get the connection lost error.
Claus
I have two ideas.
1) Maybe different library versions are the reason. On the x86'er, I use Ubuntu as compile system. For the RPI, raspian is the compile system.
2) I can use raspian in a qemu VM to check if it's running if the server run on a other raspian system. So both will use the same library versions.
Claus
I do not believe in library problem, since the network protocol does not use much external libraries.
But different processor architecture might have an impact! (You might use the windows client for testing)
All you can do for diagnosis is to put log messages to the protocol part of the vompserver and client in order to figure out, which command of vomp is failing and causing a connection abort. It is probably something that is interpreted on the cpu of the raspberry in a different way then x86. (Please look at the arm patches around in the forum, may be not all are in git yet).
Marten
Hi,
is it possible to connect with wget, curl or telnet to the vompserver and send a command to activate a video stream? If yes, how? This will make the debugging much easier.
Claus
No, not practically, it is a binary protocoll.
Marten
Hi,
now I have a response from a other user, who has test the Windows client against the vompserver that is running on the RPI, see the last post at http://www.minidvblinux.de/forum/index.php?act=ST&f=25&t=4868&p=33122&st=240 . This is running without problems.
So both, my vompserver and my vompclient working well at the RPI. The only problem is, that they can not both at the same machine.
Claus
Well, anyway you have to find out what causes the connection lost, there are various reasons....
Also I do not know if the raspberry has enough power to have both vdr and vomp on it.
Marten
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
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
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
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
No I have no idea, maybe some socket options has to be set.
Well, the standard idea, play with the tcp window size....
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
Well, they do not have to match, but anyway you should just try different settings.
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.
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.
Hi Chris,
Quote
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
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
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
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
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/7Do you have any idea how I could solve the problem "Connection lost"?
tvia
hi,
no idea?
tvia