Topics

Hi,

I noticed that the time on my vompclient was 2 hours wrong. 2 ours off where I live usually means that the timezone information is wrong. When I debuged this I found out that the read offset at the vompclient was always zero. I suspect that the timeOffset send is send in the wrong way. If I change vompserver code according to the diff below the time is set correct on the client. I'm not experienced at using the htonl functions so I may be wrong. The type of the tm_gmtoff member should however be long!

Code Select Expand


===================================================================
RCS file: /cvsroot/vomp/vompserver/mvpclient.c,v
retrieving revision 1.38
diff -r1.38 mvpclient.c
277c277
<   int timeOffset = timeStruct->tm_gmtoff;
---
>   long timeOffset = timeStruct->tm_gmtoff;
282c282
<   *(signed int*)&sendBuffer[8] = htonl(timeOffset);
---
>   *(ULONG*)&sendBuffer[8] = htonl(timeOffset);


- Magnus

Hi,

I have been struggling the last week to try to patch the vomp development environment to create a bootable dongle. Carefully examining the steps used in the mvpmc project I did the following.
Kernel patches - These are also used by the mvpmc project and can be found in their git repository.
1. hcwmp_header.patch
1. squashfs_2.2r2.patch
2. zlib.patch

Instead of extracting the kernel modules from a hauppauge dongle I use the one existant in the mvpmc git repository

One also need to change the dongle_build.sh script to copy the kernel modules mentioned above and create a squashfs filesystem. The mksquashfs tool to use is the one used by the mvpmc project. Its squashfs2.2-r2 thats used but its patched to take -if argument that allows one to create device inodes on the filesystem.

I'm attaching the a tar'ed set of files that shall be untared in the root of the vomp project. Run the kernel_patches.sh script to apply the patches. Note that the mksquashfs tool is not included!

I need some feedback though since the build dongle is not 100% functional - I cannot watch live tv wich is sort of essential. The strange thing is that if I use the mvpmc build suit and substitute the mvmpc client sources for vomp client sources I get a dongle with wich live tv can be seen!

The message I get, with the patched vomp buildsystem, is an dialog saying Connection Lost when I try to view a live tv channel.

Please give feedback. If someone knows a way or has ideas on howto extract the kernel modules from the hauppauge dongle with squashfs I'm willing to give it a shot.

In my last post I outlined the steps I have taken in order to build a vomp dongle for the H3 hardware. After adding the missing jpg files to the  root of the filesystem and actually starting vdr with the vompserver plugin I can conclude that it works!!

So far I have only tested to watch live tv on a few channels. More tests will follow...

- Magnus

Hi All,

Thought it was time to brief the list of some progress that I have had in my attempt to port the H3 hardware to run VOMP.

At first I had a shot at setting up the develpment environment on an x86_64 machine but that did not work for me so I took one of my retired x86 machines and turned it into a VOMP development machine.

Since the vomp project build didn't succeed due to problems with the split_dongle script I decided to use the mvpmc project as base since it actually produced a dongle that worked for me on my H3 hardware. In order to get a vompclient I followed the following steps.

1. Fetched the latest mvpmc sources from the git repository.
2. Moved the original mvpmc/src folder to src.org.
3. Creeate a soft link to the /vomp/vompclient directory named src
4. Copied the SConstrict file from src.org to the src directory
5. Modified the Program section in the SConscript file to include the vompclient source files.
6. Modified the LIBS to use only pthreads, jpeg, rt and stdc++
7. Modified mvpmc/src/main.cc to not init and shutdown the MtdMVP class instance. Defaulted the videoFormat to Video::PAL
7. Added a env.Replace(CXX = cross + 'gcc') to the mvpmc/SConstruct file in the section where the compiler is setup for the mvp build.
8. Build the dongle with make mvp

Putting the dongle files on the tftp server with dhcp, tftd and mvprelay configured correctly make the H3 boot up (Guides for setting up mvprelay etc for H3 hw can be found on mvpmc wiki)

Telnet'ing to the mediamvp and executing the vompclient binary then gives:

# vompclient -d
18:06:34.681507 [info]   Core - Starting up...
18:06:34.682245 [info]   Core - Signal handlers set up successfully
18:06:34.682865 [info]   Core - Remote module initialised
18:06:34.683366 [info]   Core - LED module initialised
18:06:34.683836 [info]   Core - Mtd module initialised
18:06:34.685376 [info]   Core - Timers module initialised
18:06:34.685888 [info]   Core - Read from MTD: PAL 720x576
18:06:35.120155 [debug]  Video - Setting aspect to 0
18:06:35.130090 [debug]  Video - Setting aspect to 0
18:06:35.610085 [debug]  Video - Setting aspect to 0
18:06:35.611040 [info]   Core - Video module initialised
18:06:35.695059 [info]   Core - OSD module initialised
18:06:35.704087 [debug]  Audio - MUTE OFF OFF OFF
18:06:35.704625 [info]   Core - Audio module initialised
18:06:35.705100 [info]   Core - VDR module initialised
18:06:35.705560 [info]   Core - ViewMan module initialised
18:06:35.706023 [info]   Core - Command module initialised
18:06:35.706485 [notice] Core - Startup successful
18:06:35.707079 [debug]  Box - Construct, now 1
18:06:35.707605 [debug]  View - Construct 0x100c2568, now 1
18:06:35.943547 [debug]  View - Destruct, now 0
18:06:35.944091 [debug]  Box - Destruct, now 0
18:06:35.944627 [debug]  Box - Construct, now 1
18:06:35.945116 [debug]  View - Construct 0x100c26c8, now 1
18:06:35.945639 [debug]  Box - Construct, now 2
18:06:35.946124 [debug]  Command - PAL wallpaper selected
18:06:36.075583 [ERR]    BJpeg - Can't open JPEG
18:06:36.181650 [debug]  Box - Construct, now 3
18:06:36.182165 [debug]  View - Construct 0x100c4960, now 2
18:06:36.212116 [debug]  VConnect - Draw done
18:06:36.212769 [debug]  UDP - Starting UDP command server
18:06:36.251722 [debug]  UDP - Starting wait
18:06:36.252400 [debug]  UDP - UDP command server started
18:06:36.253235 [notice] VDR - Broadcasting for server
18:06:37.750262 [notice] VDR - Broadcasting for server

From the log it actually seems as if the vompclient is up and running. Before I evolve any further e.g. adds the missing jpeg files to to filesystem and fixes that the client finds my VDR machine I would like some feedback from you guys reading this list.

1. Will the approach taken above work or are there some missing propritary binaries that must be used from the hauppauge dongle.
2. Are there any drawbacks compiling with the gcc-3.4.5-uClib-0.9.28 croostool instead of the one used by the vomp. (The gcc-3.4.5-uClib-0.9.28 is used by default by mvpmc builds)
3. What file should one modify to change the application launched when the dongle is booted and the kernel is started.


- Magnus

Hi,

I got one of these new H3 mediamvp's. In an effort to sort out the problems with this hardware I thought a good start would be to set up a development environment for vomp. I'm on a gentoo x86_64 system and the crosstool build fails. Everything works fine until configure is executed in the gcc folder...

I'm writing this from work so I don't have the exact message at hand but its something about x86_64 beeing an unknown host. I can supply the error later today.

I have also tried crosstool-0.42 downloaded from http://kegel.com/crosstool/
A build of crosstool for the powerpc-405 cpu with gcc-2.95.3 and glibc-2.2.5 fails with the same error as indicated in the Crosstool build result matrix - http://kegel.com/crosstool/crosstool-0.42/buildlogs/

Anyone know of a solution other than performing the crosstool builds on a non x86_64 machine?

- Magnus