Messages

Thanks Forty2 for the outline of grabbing the kernels from the newer dongles. I'll try the tip. I had it all figured out except for the find-squashfs part...

Regarding the livetv problem I'm getting more and more confused. For some reason I had commented out the call to clock_settime when I build using the mvpmc devenv a couple of weeks ago. Now when I dig deeper into the problem I found that its enough for me to log into the mvp and set the date/time to be anything before the time the show to watch started. Lets say that the current program on channel 4 started at 2006-10-08 18.20 and then setting the date/time with 'date 100718152006' from the console before entering channel 4 brings up livetv.

Its gotta be something with the epg code or epg data! If I disable the code in VVideoLive::doBanner I can watch livetv without problems.

Right now I'm uncertain wether the problems I see are due to my H3 hardware, my vdr setup or with the vompclient/vompserver codebase!

Issues:
* The above mentioned problem with VVideoLive::doBanner code that causes connection lost on my client.

* I cannot choose the first channel in my vdr list. I can watch it without only problems on the vdr machine but when I choose it on the vompclient I get a "No such channel" dialog.

* The channel numbers are not as setup on the vdr machine. I have six channels setup with channel numbers from 1 to 6. In the vompclient channel menu these channels are listed with numbers 0 2 3 4 5 6. Its when I choose channel 0 I get the No such channel.

* When I enter the recordings menu the vompclient segfaults.

The issues above are for a cvs update from  2006-10-07

The corresponding functionallity when performed on my vdr box works fine!

Hints are welcome. What problem shall I attack first?

- Magnus S.

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

The only required change is the hcwmp_header.patch
The patch can be found attached to my previous posting or from the mvpmc git repository. Apply the patch rebuiild the kernel and test to see if it works on your hardware. I would be suprised if it caused any trouble since its allways applied on the kernels build for the mvpmc project.

Instead of using the newer hauppauge dongles I downloaded an old one and have no problems with the rest of the build. Would be nice though if someone could actually come out with a way to extract the kernel modules from a newer kernel!

I have now gotten it to show livetv using a checkout from 2006-10-01 where I have made this small change:

myth@sam ~ $ cd vomp
myth@sam ~/vomp $ cd client
myth@sam ~/vomp/client $ cvs diff
? vompclient
cvs diff: Diffing .
Index: main.cc
===================================================================
RCS file: /cvsroot/vomp/client/main.cc,v
retrieving revision 1.28
diff -r1.28 main.cc
193c193
<   success = mtd->init("/dev/mtd1");
---
>   success = 1; // mtd->init("/dev/mtd1");
215c215
<   UCHAR videoFormat = (UCHAR)mtd->getPALorNTSC();
---
>   UCHAR videoFormat = Video::PAL; // (UCHAR)mtd->getPALorNTSC();
404c404
<     mtd->shutdown();
---
>     // mtd->shutdown();
Index: vdr.cc
===================================================================
RCS file: /cvsroot/vomp/client/vdr.cc,v
retrieving revision 1.39
diff -r1.39 vdr.cc
292c292
<   int b = clock_settime(CLOCK_REALTIME, &currentTime);
---
>   int b =  0; // clock_settime(CLOCK_REALTIME, &currentTime);
cvs diff: Diffing fonts
cvs diff: Diffing other
myth@sam ~/vomp/client $

Watching recordings does not work. When the recordings menu is entered the vompclient segfaults.

I haven't had time to investigate the result of the clock_settime call yet. I will investigate this over the weekend.

- Magnus S.

Hi again,

Carefully reading the mvpmc dev mailing list I just realized that the only patch needed to the kernel is the hcwmp_header.patch This is a good thing...
So all parts in the patches that relate to squashfs can actually be ignored. One must however still use the pre extracted proprietary kernel modules since I still have no clue on howto extract them from the new hauppague dongles.

Chris/Mark: Any chance of getting the hcwmp_header.patch into the makedevenv-2 script If I understand things correctly the patch doesn't cause any problems for older hardware. Needs to be tested by someone though...

Chris/Mark: Do you want me to create a new patch wich only contains the smallest amount of changes to build a Hx bootable dongle.

The squashfs support is perhaps something that might be of interest later...

My previos request for an 'ls -l /dev' can be ignored. When I reverted the dongle_build.sh script back to create an ext2 filesystem I noticed the use of the spec file. The spec file is basically the same as the devtable file used as input to the patched mksquashfs command.

I'm still however having problem getting any livetv to work even with only the hcwmp_header.patch applied to the kernel.

- Magnus S.

Thanks for the reply,

I'm using vompserver and client sources check out from 2006-08-01 (cvs update -D 2006-08-01) which essentially should be the same as the 0.2.4 release. (I suggest that the cvs sources are tagged in forthcomming releases :-)). Note that the sources work if compiled with the mvpmc development suite.

I also doubt that the smc91111.patch solves the connection lost problem as that patch is only applied on the 2.4.31 kernel in the mvpmc project and I compiled using the 2.4.17 kernel.

Would it be of any help attaching the trace I get by running ./vompclient -d or the vompserver log? I tried this morning changing the tcp receive buffer to no avail but causing crash when the buffer was set to 1024. All other buffers caused the connection lost dialog.

One thing thats bothered me while working on this was the devtable file passed as argument to the mksquashfs tool. What devices shall really be in /dev ? Could someone perhaps post an 'ls -l /dev'

-Magnus S.

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.

When building mvpmc you have the choice of using the 2.4.17 kernel or the newer 2.4.31 kernel. They both produce a dongle that can be used. Live tv isn't as smooth as I would like it to be but that can be caused by poor performance on my network and/or on the machine running vdr.

So far I have only tested compiling with gcc-3.4.5-uClibc-0.9.28. Next step is to try gcc-2.95.3-glibc-2.2.5 instead as its supposed to create a more stable kernel.

- Magnus

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 again,

I took another shoot on my x86_64 machine last night and had some success. Its a hack and someone better in "crosstooling" could suggest the correct solution or provide an approriate patch to the crosstool suite.

I manually edited crosstool.sh on line 88 where the HOST variable is set from :

84 # Set HOST to something almost, but not completely, identical to BUILD
85 # This strange operation causes gcc to always generate a cross-compiler
86 # even if the build machine is the same kind as the host.
87 BUILD=`$GCC_DIR/config.guess`
88 HOST=`echo $BUILD | sed s/-/-host_/`

to:
88 HOST='echo i686-unknown-linux-gnu | sed s/-/-host_/'

This single change made the crosstool suite to complete on my box. I guess that a ./configure --host=i686-unknown-linux-gnu in the gcc directory would have the same result. Perhaps theres a way to tweak this into the dev. env. build script?

I haven't actually been able to run any code yet on the target so that I can confirm if the crosscompile actually works but everything builds.

Now its time to tackle the H3 hardware problems...

- Magnus

Hi,

I tried the suggested changes but to no avail...

Well I guess its time to fire up a xen host domain with a 32 bit kernel to use for my vomp development.

- 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