Messages

  Actually Chris told me on Sunday about your account not being activated, so we'd already guessed that part of the story!

I'm glad it's all working for you now. Enjoy 

I keep getting bounce messages when sending mail to you, and I can't connect directly to the mail server either 

I'll send you a PM on here instead -- or I would, but that's not working either 

If I still can't get a message to you by the end of today I'll just create a throw-away account and post the password on here 

Thanks for the info. I have sent you an email.

(Hmm, I received a delivery failure on Saturday morning. I've re-sent the message...)

Hi Ulrich,

Sorry for not replying sooner... if you're still having problems, I'll need to have a look at one of the recordings to see what's wrong. If you could put the first few megabytes of the 001.vdr file somewhere for me to download (10 MB will be plenty) along with the index.vdr, I'll take a look. If you don't have anywhere on the Web to upload it then I'll open an ftp connection for you to use.

What version of VDR are these recordings made with?

Chris mentioned to me a while ago that one of the things on the "to do" list is some way of transferring general data/files via VOMP protocol. The first application of this was likely to be for the i18n (or should that be l10n?) data and/or fonts. Now that people are asking for logos, perhaps that will be easier to start with :-)

The patch below makes it compile, but my VDR is in use at the moment so I can't upgrade and test it out. It's the logical fix though... hope it works.

Code Select Expand


diff -ruN vompserver-1.4/mvpreceiver.c vompserver-1.5/mvpreceiver.c
--- vompserver-1.4/mvpreceiver.c        2006-03-01 22:29:01.000000000 +0000
+++ vompserver-1.5/mvpreceiver.c        2007-01-16 18:53:27.000000000 +0000
@@ -25,8 +25,10 @@
MVPReceiver::MVPReceiver(cChannel* channel, cDevice* device)
#if VDRVERSNUM < 10300
: cReceiver(channel->Ca(), 0, 7, channel->Vpid(), channel->Ppid(), channel->Apid1(), channel->Apid2(), channel->Dpid1(), channel->Dpid2(), channel->Tpid())
-#else
+#elif VDRVERSNUM < 10500
: cReceiver(channel->Ca(), 0, channel->Vpid(), channel->Apids(), channel->Dpids(), channel->Spids())
+#else
+: cReceiver(channel->GetChannelID(), 0, channel->Vpid(), channel->Apids(), channel->Dpids(), channel->Spids())
#endif
{
   logger = Log::getInstance();


Hmm, actually, I was a bit wrong last post: the sdram-bank1 code only checks for the HCW_MVP magic string, not the version numbers.

You could be right about the version numbering and the reboot issue, but I think Magnus is using the same dongle_version.h as mvpmc (with alpha flag) and still has the problem. I do feel that it must be something in that area though!

Right, having looked at the Hauppauge tarball, mvpmc's scripts and your latest post, I think you're spot on. Basically we just need to update our build scripts to incorporate stuff from the Hauppauge tarball, like mvpmc have done. And like you have done: thanks! 

I don't have access to an H3, but I'm going to build a dongle using your method and check that it boots on my old MVP. Then, there's just the H3 reboot issue that needs sorting. You say it doesn't happen with the latest mvpmc dongle, so what's different between us and mvpmc? I can only see two things immediately: they're using a uClibc toolchain from buildroot, and they're also using squashfs.

I don't see logically how using a different libc could make a difference, but I don't understand it well enough to be sure. Could there be something in the squashfs patch that helps? Possibly. There definitely is something in there that checks against the MVP dongle version numbers in head.S (from dongle_version.h and mvp-version.patch) and might have something to do with checking whether an H3 MVP is booting from flash or a network dongle. Actually, the code I'm talking about is in sdram-bank1.patch, but it's only triggered if squashfs is enabled instead of the usual CONFIG_BLK_DEV_INITRD.

So I'll also try building dongles with the Hauppauge uClibc toolchain, and then with both that and squashfs. If they all boot on my old MVP, then perhaps we could try on an H3. However, like Chris, I wouldn't like to have to move to squashfs, so I hope that doesn't fix the problem!

I'm talking about this tarball, which Chris brought to my attention last week:

http://www.mvpmc.org/dl/mediamvp-20060728-dist.tar.bz2

(You may have known that already; just making sure!)

To me it looks like something Hauppauge have put together themselves, with the stuff in the toolchain directory being a crosstool-style "download it all and build it" affair. It's probably influenced heavily by crosstool and/or buildroot, but I haven't examined it closely.

From what I can gather, the rest of the tarball is all about running make in the src/ directory, which puts a root filesystem together, compresses it into a squashfs, copies it into the kernel tree and then runs 'make zImage.initrd' on the kernel. The patches have modified the kernel tree such that a dongle.bin magically pops out. At least that's what it looks like; I'm getting close to testing it.

Of course the existing src/ directory doesn't do much as it stands, because all the Hauppauge client stuff is missing. But I'm hoping I can make a vomp/ directory with a similar structure that does what we want. At the moment I'm just going through each step manually to make sure I understand the process.

Hi,

This topic is actually the 'big thing' at the moment, as Chris now has access to an H3 he wants to get working cleanly, and I'm interested in moving away from the ancient gcc/glibc & Montavista kernel, and getting VOMP working with a better dongle build method.

Right now I'm trying to build a dongle using the Hauppauge toolchain that Chris mentioned (gcc-3.4.4/uClibc), along with the 2.4.31 kernel, patches and build procedure. I'll keep the thread posted...

Thanks for all the work you're doing on this: it's much appreciated!

Yes please, if you could create a new patch with just the required changes, that'd be good. Then we'll test it on the older hardware.

Regarding the dongle build method, squashfs or whatever, I was talking to Chris a couple of weeks ago and he mentioned that sometime he'd like to investigate the various options, find out what they actually are and how they work, and decide what's best and easiest to use. In the time being, if we can get it working with the existing script, that'd be great!

Your live TV problem: yes, please attach the client and server logs. Does everything else work apart from live TV? You haven't seen any problems at all with playing back recordings?

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_/'

Hmm, that's what I was trying to achieve. It seemed that crosstool.sh initially set BUILD to GCC_BUILD, when I had a quick look.
I'll investigate it further tonight... perhaps 'unknown' is required instead of 'pc'... or perhaps setting BUILD to i686 hurts something else.

Well done for getting it to work... and good luck with the H3!

[Edit: as it turns out, I was looking at the wrong version of crosstool myself (0.39), so I'm even less surprised that my suggestion failed )

OK, quick stab in the dark here...

Try setting an extra environment variable in the dev. env. build script:

export RESULT_TOP=${CROSSTOOL_TARGET}
export GCC_BUILD=i686-pc-linux-gnu
eval `cat powerpc-405.dat` `cat gcc-2.95.3-glibc-2.2.5-ppc405.dat` sh all.sh --notest

(The middle line is the new one).

You might also need to add
export CC="gcc -m32"

I really don't know... I'd be amazed if this works, but it's worth a try. It's just guesswork
Someone who actually has a 64-bit box might be more help than me!

If I remember properly your UK DVB-T channels have one frame per PES packet, thus if the error have something to do with the several frames per pes packet patch, you and Chris won't detect it.

Yes, all recordings of UK channels that I have seen start each frame in a new PES packet. They also have a PTS for every frame, while some German channels (including the sample Schnurps gave me) only have a PTS every 12 frames (i.e. one per I-frame).

VOMP actually still doesn't cover the case where two frames start in the same PES packet. I need to fix this, but since VDR chops the video into 2K packets, it is unlikely that more than one frame start code will appear in the same packet. There also appears to be code in VDR (cVideoRepacker class) to ensure that each frame starts in a new packet in the recording, but I'm not sure if this is in use yet (there are some 'TEST' #ifdefs that refer to this class, at least in 1.4.1.) That won't help with recordings from previous versions of VDR though.

When I made this latest fix, I did plenty of stress-testing by skipping around like crazy, including skipping across and near PTS discontinuities, and didn't experience any problems, so it could be dependent on the format of the recording, or maybe I was just lucky.

Hi,

Yes, we know about this. It happens because VOMP buffers a few seconds of video on the MVP, but ends the playback as soon as VDR stops sending data, so the last few seconds are 'trapped' in the buffer and never get displayed.

We've really just ignored it so far because it usually doesn't matter for TV recordings. I'm sure it will be fixed at some point, but how soon depends on how complicated it is. It seems like it should be simple but it might make a mess of the threading code. We'll see what Chris thinks...

Mark