Messages

Before I found the vomp server I played around something with the mediamvp project. They are using the Nano-x (microwindows) for osd output. One of the biggest advantages of this project is that the use a cross-compiling system. You can compile and run the prog for the mvp also under X11, so it is very easy to modify and debug the prog.

The problem (for us) of this project is that they don't support the vdr, there main-target is the MythTV, I was only able to play some media-files (with nfs mounted vdr).

A vnc-client is part of the samples comming with the microwindows system, this could perhaps be a bridge to the ffnet-plugin. It's a bit tricky to compile it for the ppc-target, (normally if you choose ppc as target compiling of the microwindows samples fails) but I was was able to compile some of these samples with modified make files. After that you can run the binaries inside the mvp but the remote control is acting as a keyboard and it is nearly  impossible to use the programs. But I didn't try that with the vnc-client.

Perhaps you can try this way, implementation into vomp would be very easy.
We run vomp not directly from /etc/rcS, instead we run a shell script. Inside this script we have all vars we need to run the vnc-client (ip-adress of vdr-server running vomp-plugin and ffnet). Your new "Server" Button could exit vomp with a specific exit-code, if the shell script finds that exit-code you run the vnc-client, after exiting this (how to exit the vnc-client???) vomp again.

These would bring a full-featured vdr-osd to the mvp, but no video and no audio. But for testing the ffnet-plugin this could be usefull.

If you need some help to set up the cross-compiler enviroment (you need at least gcc 3.3.3 with uClibC for ppc)  please ask.



Klaus

thank you

yes sounds very interesting. To use this it would be necessary to write something like a vnc-viewer and overlay  the video output on the mvp. Not even done in some hours, but would be a universal solution. 

Isn't something like a vnc-client part of the mediamvp project ?

Klaus

I also thought about vdr's without ff cards. (even more important cause chris is using only passive adpters in his vdr.....).

But I think this would make the job very diffficult. I thought about a very very simple solution. With ff-cards you have access to that device (for example vdradmin, fbtv, xawtv etc), and inside is the osd. In client mode the mvp would display this stream. 

On the other hand all commands from the remote-control are send to the vdr - at first moment we could use the existing control-plugin and telneting this plugin - only for testing purpose.

What I don't know: Could data from one of this devices  (/dev/video or /dev/dvb/adapterX/video0) be transported from the vomp-plugin like a "normal" recording or livestream??

Would be so great: An horrible loud but fat and fast linux-server downstairs - small and tiny clients in the livingromm, acting like the original ........

But perhaps I kneed to more about ffnet - could you provide some infos ?

Klaus

Would this work ?

grab vido output from /dev/dvb/adapterX/video0 and send this to the mvp (instead of  a selected channel) this stream contains also osd output (like fbtv does).
In this mode all commands frome mvp's remote-control are send directly  to the vomp-plugin, the vomp-plugin controls the vdr  like the control-plugin does. Would be a perfect  vdr client , with all features of the vdr : mp3, define recordings, create dvd all you can do with the vdr menu.

Would only work with ff-cards....

klaus

I did it that way:

change line 51 in mvpserver.c to

  log.init(Log::DEBUG, "/tmp/vompserver.log", 1);

so the plugin will create a log-file in /tmp.

create a shellscript (shutdown-hook script) -in my case in /usr/share/vdr/shutdown-hooks/shutdown82.vomp.sh

###########################################################

#!/bin/bash
JOBFIL="/tmp/vompserver.log"

if [ ! -f $JOBFIL ]
then
    echo $JOBFIL not found ! Creating empty one !!!
    touch $JOBFIL
fi

let LINES=0
LINES=`cat $JOBFIL | wc -l` 
if [ $LINES -gt 0 ]
then
    logger -t $0 "vompserver activ - cancel shutdown ..."
    TRY_AGAIN=10
    cp ${JOBFIL}.002 ${JOBFIL}.003 2>/dev/null
    cp ${JOBFIL}.001 ${JOBFIL}.002 2>/dev/null
    cp $JOBFIL ${JOBFIL}.001 2>/dev/null
    cat /dev/null > $JOBFIL
else
    logger -t $0 "vompserver not activ, bye..."
fi

###########################################################

It's not a very advanced method, but working really good....

klaus

Also works fine with wlan g+ (dvb-s live and recordings). vdr 1.26 / dongle 15 / plugin from cvs.

Thanks for that patch.

klaus

Hi Chris,

I've played a lot around with the network, here my results. Vomp is now running nearly perfect with the wlan adapter, and this was the reason that I did all this experiments.

I also checked the mailing list from mcpmc and found this article (route with window 4096). But I personally can't reproduce that behaviour. I wrote a little prog in c, that checks out the current network-address, and with that adress I do an automatic set of the route with that specific window size (during boot - before the client starts).

The result is that the network is slowing down significant. With this window size I'am not able to view a live-signal / or a recording from a dvb-s vdr (stuttering pictures /broken sound). From a dvb-t vdr it's possible, cause the bandwith is smaller. (all in the wlan segment).

Curious: If I copy a file (inside the mvp) from one nfs-volume to annother there is nearly no difference (with or without window size), but streaming seems to be annother thing.

So I decided to hook into your programming (very very interesting - perhaps some more comments ....) and wrote me my own class. Inside I implemented a text-window in which I can see the result of the ifconfig command. So I can monitor on TV whats's going on. Indeed we have some overruns in the wlan segment. I started the mvp this mornig with live-tv and now (may be 6 hours later) I have ca. 1100 overruns (RX packets). But I can access the box from outside, the ip stack does not crash. So I'am not really sure if we need this route command, I think we need more experience.

Annother thing is my 10MBit segment, there are more problems, after booting the new image with the patched client and no route command, there are more then 1000 (overrun) errors already after 5 minutes of viewing live-tv, the picture is stuttering sometimes - sound also. But also here: I can access
the box from outside, the ip stack does not crash, and I have something on TV. Don't know if there is a lot of traffic inside this segment - perhaps the neighbours are heavily accessing the network, I have to investigate this.


Thanks again for your excellent work!

I hope you enjoy your travel......

Klaus

great !

Thanks a lot.
I think it was difficult to detect and to find an enviroment in which it (definitivly) not was working.
Wen we'll you be back, I'am also so impatient to see the new radio function.....

klaus

Hi all,

I read in another forum that the mvp has problems in mixed networks (falls to half-duplex) under some circumstances. With the vomp plugin/server we have observed sometimes also network problems (channel not available / cannot play recording etc).

I played a lot around that problem and I figured out that if one of the partners (the vdr or the mvp) is operating on 10 MBit/ half or full duplex, vomp does not operate properly. Please to all: Could you reproduce this behaviour ?

It's easy to test that by setting eth0 of the vdr to 10MBit mode with the tool mii-diag. The call is

mii-diag -F <val>

   -F  --fixed-speed <speed>
        Speed is one of: 100baseT4, 100baseTx, 100baseTx-FD, 100baseTx-HD,
                         10baseT, 10baseT-FD, 10baseT-HD


I tested it on two different networks, on both I could reproduce it. Thanks a lot


Klaus

yes - but it is not very comfortable. At the moment I load the vomp-image via mvploader. In this case it makes no difference from which server I load it. If I want to boot a different image (for example that from mvpmc) I have to edit my dhcp-server to tell him which image to boot.

But there are no conflicts, vomp seems to coexist with the other mvp apps.

Thanks

Klaus

At home I have two vdr-pc. Normally both are connected on a 100 MB Switch. The vomp plugin works fine.
I have an uplink from the 100 MBit switch to an 10 MB hub. The 10 MB Hub serves some older computers which are connected via rg-58 cable (my loved neighbours) to my network.

I connected the mvp to the 10 MB hub and the MVP with vomp immediatly fails to operate properly.
It loads the channel list and I'am able to selet a Channel, but then I can see the EPG and immediatly there is the "Channel not available" MSG, also I can't play recordings, same effect.

To verify the network, I connected the vdr (192.168.3.214) to the 10 MB Hub, the other (192.168.3.201) stays connected on the 100 MB switch. I'am able to use the stremdev-client on the "slow-connected" machine, also I'am able to view a recording from the (fast-connected) machine. I can copy a recording from one machine to the other, if I try to view a channel (during copy) on the other machine this works, but there are some artefacts and other disturbs - in my opinion the network is operating well, only slower.

Then I switched to ethereal and grabbed the traffic between (192.168.3.214) and the MVP (192.168.3.204).
You can download this capture here (and load it into ethereal) (I was not able to upload it here, please dl from http://videotext.dyndns.org/vomp/mvp_hang.gz .

Today a friend of mine (who is more advanced in protocol analysing) had a look at the protocol and for him it seems to be ok.

But the point I want to figure out is the following: Client on MVP is connecting, gets channels, gets EPG, then there is nothing for about 2 seconds (this is at Packet Nr.80 in the log) and then the vdr begins to send packets (and these packets are in my opinion normal data-packets of size 1542), the MVP sends ACKS, all seems to work properly, only the client on the MVP seems not to work with this data ....


so far perhaps this can help, if you need more please let me know.

klaus

hi chris,

meanwhile I feel with you......

That's really  a uggly uggly uggly problem. Now that I lost some hours I shortly want to tell what happened. I took the second box today to the office for testing it after work. I'am using to machines here and both are running a vdr. Suddenly I was not able to switch a channel to annother one outside the bouquet, always channel not avail.

I observed similar situations earlier with the streamdev-plug. So I installed a newer ver of dvb-driver (from 1-0-1 to 1.1.1). But it was  not perfect, I switched to a radio channel on vdr (266), and was not able to switch the mvp, I switched to a radio channel (220) resetting the mvp and was able to switch the mvp. I figured out that it was exact the channel 265, below it worked, above not. I retried that many times cause I want to find reproducable results. Then I copied this channels.conf to the other machine (1.0.1 dvb-driver) what do you think: It worked for channels above 265.....

I came back to the first machine - believe me, I didnt do any change to that system, and it was also working on that machine. During time when it not worked properly I had some getBlock timeouts in my log:

19:48:07.960817 [debug]  Client - Got channel
19:48:07.960848 [debug]  Client - Got schedule!s! object
19:48:07.961009 [debug]  Client - Got schedule object
19:48:07.961067 [debug]  Client - Got all event data
19:48:07.961129 [debug]  Client - written 4 schedules packet
19:48:07.961195 [debug]  Client - Waiting
19:48:07.973492 [debug]  Client - Received packet, length = 16
19:48:07.973589 [debug]  Client - getblock pos = 0 length = 250000
19:48:07.973635 [debug]  Client - getting from live
19:48:12.560024 [debug]  MVPReceiver - getBlock timeout
19:48:12.560120 [debug]  Client - VDR has disconnected the live receiver
19:48:12.560151 [debug]  MVPReceiver - VDR inactive
19:48:12.560893 [debug]  Client - written ok 0
19:48:12.560962 [debug]  Client - Waiting
19:48:12.922989 [debug]  Client - Received packet, length = 4

Always when I tried to switch via mvp and I received a channel not avail. I was not able to leave the bouquet on vdr, I always had to restart the vdr to release it.

Later I tried to produce traffic on the network (filecopy and more) but nothing helped, it was running running running, I can't reproduce the earlier state. That's the sort of bug we love soo much ........

The timeout error in tcp.cc (10 sec.) wasn't seen during all the time, I think you're right, 10 secs is enough - what with my other getBlock timeouts?


klaus

My kernel is

uname -r
2.4.26-ctvdrskas-1

This is a well tested kernel espacially vor v4l apps, published by a big german computer magazine (ct).

...have no idea how moving from 10Mb to 100Mb could make any difference ...

I think there is a difference. The 10 MBit switch is linked up to a 100MBit (there's playing the music...) and in another collision domain. The problem occurs in the moment we begin to stream. Maybe the problem is a lower level problem (below IP)

If I can do some tests for you let me know, today I bought a second mvp.....

klaus

I have a feature request: If the automatic shutdown feature on vdr is enabled (menu//setting/other/min. user inactivity > 0)  it will shutdown, even if a mediamvp client still is active (live-tv or recording). There are two possibilities to prevent this:

a) directly in the plugin
b) with a shutdown-hook script

a) only could be done by the develteam, solution b) is realised by scriting, but in this case the script has to detect that there are active clients. I played around something with netstat, but can't detect some usefull information.

Any idea?

Thanks

Klaus

I also observed this, seeing the recordings and playing them shots mvp into the nirwana...

In my case the solution was to connect the mvp to the 100 MBit switch, before it was on an 10 MBit switch. The mvp-client seems to be very impatient, perhaps chris can change this behaviour a little bit.

greets

klaus