Messages

Snapshot dongle available:

http://www.zen50618.zen.co.uk/vomp/vomp-dongle-cvs20060818

Reading this thread and the comments on vdrportal.de, I believe a lot of people are awaiting the release of the fixed dongle. Is it possible to upload a temporary file for all who "suffer" from this annoying bug?

Seems strange the bug is already solved but nobody can enjoy this new software....?

I know... 0.2.4 was done in a bit of a rush. This bug was fixed a week after the release, but I don't think we realised just how long it would be until 0.2.5, or how many people had the problem.

I'll find time to build a cvs-snapshot dongle over the weekend.

Thanks, I downloaded the files you provided.

The recording works fine with CVS vompclient. I forgot that there hadn't been a dongle release since I fixed this bug.

So... it will be fixed in 0.2.5 (I hope!)

It sounds like the demuxer is not counting the frames properly. I know about one possible problem: if more than one frame begins in the same PES packet, the demuxer will not count them all. But I looked at the VDR code and it seems to guarantee that each frame will start in a new packet. I notice that tobi_w and Toxic-Tonic are using VDR 1.4, so it can't be the VDR version.

Would it be possible for you to make a small amount of one of these recordings available on the 'net for me to download and examine? I probably won't need a lot... one or two megabytes should be enough. If you don't have anywhere to put it then I'll open up ftp on my box for you.

Well spotted - thanks for reporting the problem.
I think your patch would work fine but actually Chris and I agreed that the player should only call seek() for video playback. Seeking doesn't make sense with radio because the purpose of seek() is to find a video I-frame.

We handled this correctly for live playback but not, it seems, for recordings. We'll have it fixed in CVS pretty soon.

Mark

Definitely a hardware problem my end.
The point I am making is that considering the remote still works with the original MedaMVP software, perhaps the IR remote decoding mark-space timing in Vomp is too tight and will not work with remotes with timing that has somehow drifted slightly.

I have not succeeded in finding a replacement remote control so I was wondering how easy would it be to edit and recompile the client software for my self to get my dodgey remote going again?

All the VOMP code does is read from /dev/rawir: all the low-level stuff is handled by one of the kernel modules, which are simply extracted from the Hauppauge dongle for inclusion in VOMP. Perhaps your Hauppauge dongle is a different version to the one we're using for the VOMP release dongles. I believe they've been updated several times over the last couple of years.

I'm not sure which Hauppauge dongle the current VOMP dongle takes its modules from; Chris will be able to tell us. If yours is different then it might be worth trying to build a VOMP dongle using the modules from your Hauppauge dongle. I'm sure there's a short cut to doing that without building an entire development tree, but I don't have time right now to look into exactly how you'd do it. Perhaps someone else has

[Edit: having said all this, I'd be surprised if much of the timing were actually handled in the kernel module, rather than in hardware, but I can't think of another explanation]

kml: Do you still have this problem? Or has anyone else experienced it?

We can't replicate the bug and we don't know what could be causing it.

howzit,

thanks for the 2.4 fixes. esp rewind.

Welcome; glad it now works for you... apart from the problems below, of course

side effects for me:

  when navigating, the progress indicator frame shoes up, but the numbers
  and yellow percentage indicator are no longer visible.

  the quick jump feature, where pressing a number would jump to that
  number*10 percentage (e.g. 5 = 50%) into the program now just
  sends me to the start. I really got to liking that feature...

Sounds like the server isn't able to tell the client how long the recording is. The % skipping now works by frame numbers, with the help of the index.vdr file.

Are you definitely running the 0.2.4 vompserver as well as the 0.2.4 client? Could it be that your VDR recordings have missing or corrupted index files (perhaps they've been edited in some way?)

What about resuming a recording from the point you last stopped it: does that work? (I'd expect it to fail if the % skipping does).

Fast forward works okay for me but pausing a fast forwarding recording fails.

Yep, there's a bug entry on the sourceforge site for that one.

Navigation of recordings with errors is much better but still fails sometimes. Blue step forward 10 seconds sometimes steps back a random amount. It seems that the first press often steps back but subsequent presses operate correctly. Letting it play a while then pressing blue again often fails again.

I suspected that recordings with errors might still be a problem. I have made another change in CVS since 0.2.4, because my code for 0.2.4 included an assumption that I knew might be wrong, and Marten reported to Chris that it was indeed very wrong on some recordings. This could be the same issue, so I'd like to wait and see if the latest fix solves this problem.

I'll have to find some way of creating recordings with errors so I can test all this properly!

On an error-free recording, the >> and << buttons shift the playback by about a minute as expected. The blue button moves forward by about 12 seconds and the yellow one back by eight. However it is not possible to do further shifts while the blue progress bar is displayed, though sometimes one or maybe two button-presses will get buffered. This is particularly irksome when inching back with the yellow button; backtracking 8 seconds then playing forward 5, backtracking another 8 and running forward 5 and so on. The phrase "one step forwards and two steps back" springs to mind

Well, I don't understand this at all. I have recordings from all sorts of UK DVB-T Freeview channels and on all of them I can skip around by 1 minute or 10 seconds, forwards or backwards, repeatedly, while the progress bar is still showing. What services/channels are your recordings from, and do they all have this problem?

Can you cancel the progress bar by pressing OK after a skip or do you have to wait 4 seconds for it to time out? If you can cancel it then you might at least be able to work around your irksome problem until it's fixed properly

Does the progress bar count correctly if you just let the recording run? E.g. if you press OK after one minute, does the progress bar read 0:01:00 or is it running slow/fast?

Mark

Happy to hear it's fixed. I was going to ask you to check out and try again, but you beat me to it.
I still don't know exactly why it was freezing, so I'm glad I don't have to investigate now!

Are the progress bar and skip/ffwd functions behaving correctly  on these corrupted recordings?

It's usually easiest to use "make release" for a dongle client, unless you have a reason to want optimization switched off.

so the VTX PID gets sorted/filtered out somehow by VOMP?
is this true?

VOMP picks out the video and audio packets, and currently it just selects the lowest-numbered PES stream for each. It recognises the "private" packets which contain teletext data but it just ignores them. VOMP currently receives live TV in the same format as a recording, so it doesn't know about TS PIDs.

For some time I've been planning to implement a TS demuxer in the client, which will make selecting audio PIDs easier, and reduce the workload and buffering inside the plugin. I've had it working before, but it assumed a perfect signal. I need to have a good look at how VDR handles missing or corrupted TS packets in order to cause the least disruption to the output.

I have to agree... Chris and I both use vdradmin-am, and I'm currently running the 0.2.3 dongle with CVS vompserver. Nothing has changed since the release, so my setup sounds the same as yours! (vdr 1.4).

The fact that you're having trouble with recordings AND timers is very strange.

When VOMP crashes with the recording list, does the server side crash too, or just the client?

Could you try to telnet to the MVP (log in as root), kill the running client (killall -9 vompclient), then run /vompclient -d, please? That will show some logging on the client side that might give us a clue.

It appears that your g++ isn't defining _GNU_SOURCE by default.
Try adding -D_GNU_SOURCE to the CXXFLAGS in the Makefile.

What Linux distribution and g++ version are you using?

I'm with lodda, and guessing his skipping problem is intermitent/content-specific. starting in 0.2.2, my skip/rewind ( |< using the original (old?) remote) on recordings didn't work right, and would often skip forward.

Yes, as MartenR suggested, this is what Chris mentioned in his release announcement: "Odd behaviour with PTS timecode jumps (timecode holes in recordings. jump keys start behaving very oddly)."

It happened in 0.2.2 because that's when we started using the timecodes to skip by exact amounts, which is nice when it works. It is very annoying when it doesn't work, and it's at the top of the "to do" list. Chris is away at the moment but when he gets back I hope to discuss exactly how we're going to fix it.