I just updated my vomp server and client source from CVS. Compiling the client produces this error:
/opt/crosstool/powerpc-405-linux-gnu/gcc-2.95.3-glibc-2.2.5/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Woverloaded-virtual -Wshadow -Werror -D_GNU_SOURCE -I../jpeg-6b -c -o demuxervdr.o demuxervdr.cc
cc1plus: warnings being treated as errors
demuxervdr.cc: In method `ULONG DemuxerVDR::getFrameNumFromPTS(long long unsigned int)':
demuxervdr.cc:252: warning: `ULONG ret' might be used uninitialized in this function
make: *** [demuxervdr.o] Error 1
There's nothing at all wrong with the code; there is no way that the variable could be used uninitialised but the compiler hasn't spotted that. This little patch shuts it up:
Index: client/demuxervdr.cc
===================================================================
RCS file: /cvsroot/vomp/client/demuxervdr.cc,v
retrieving revision 1.7
diff -u -r1.7 demuxervdr.cc
--- client/demuxervdr.cc 11 Jun 2006 21:46:52 -0000 1.7
+++ client/demuxervdr.cc 13 Jun 2006 20:35:47 -0000
@@ -282,7 +282,6 @@
++iter;
}
--iter;
- if (onTarget) ret = iter->frame;
pthread_mutex_unlock(&pts_map_mutex);
if (!onTarget)
{
@@ -291,6 +290,7 @@
}
else
{
+ ret = iter->frame;
Log::getInstance()->log("Demuxer", Log::DEBUG, "FOUND FRAME NUMBER %d for %llu", ret, pts);
return ret;
}
Hi, yes I just noticed this myself. I had just changed the code to initialise it to zero, but yours is technically better :)
Unfortunately these changes cause major problems when receiving a signal with a significant number of errors (or playing back a recording from a less-than-perfect source). Each error causes playback of sound and vision to freeze for 3-4 seconds.
Reverting the client (but with an up-to-date server) fixes the problem.
A current CVS server but 0.2.3 dongle client may be quite unstable. I will have to consult with Mark about the errors.
Just checked out CVS client again, and the latest fixes appear to have removed the 'freezing' problem.
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?
Yes the behaviour is back as it was. It is still not possible to use the ffwd / rewind buttons while the progress bar is on-screen, but I think that's covered by a bug report on Sourceforge.
Well rewind doesn't work at all, but fast forward should work. How is it in version 0.2.4?
Fast forward works okay for me but pausing a fast forwarding recording fails.
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.
(Running latest CVS client and server: vdr 1.4.1)
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 :-\
Quote from: ribanFast 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.
Quote from: ribanNavigation 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!
Quote from: davepOn 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
Quote from: MarkC on June 22, 2006, 23:35:01
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?
Recordings are from UK DTV and all channels are the same.
When I press one of the navigation buttons, the recording skips as described and the blue bar appears at the bottom showing the new elapsed time. One second later the time moves forward by 1 second. The time display then freezes for 4-5 seconds until the bar times-out and disappears. If I hit the OK button during that first second the bar disappears and the MVP will accept another navigation button press immediately; after the first second the OK button has no effect. A useful workaround, thanks!
The values on the display for total recording time and elapsed time appear correct.
I've switched to using the precompiled dongle.bin instead of the CVS version but the results are the same.
hi,
can't confirm the this particular rewind/fast forward bevaviour.
almost everything is the way it should be and is the way Mark has
described.
exept once, i sort of double clicked the "10 seconds back" button,
and then the MVP rebooted.
Quote from: Harry on June 23, 2006, 07:41:18
hi,
can't confirm the this particular rewind/fast forward bevaviour.
almost everything is the way it should be and is the way Mark has
described.
exept once, i sort of double clicked the "10 seconds back" button,
and then the MVP rebooted.
Wierd. How can we get different results from using the same software? Is it an MVP firmware thing?
honestly, i don't exactly remember whether it was the 0.2.3 or 0.2.4 dongle
(but one of these two definitely)
i remember trying to reproduce the reboot by rewinding the same
recording at about the same time index, but couldn't reproduce it.
Quote from: davep on June 23, 2006, 07:57:54
Wierd. How can we get different results from using the same software? Is it an MVP firmware thing?
No it isn't. It was a stupid hack I did a while ago to do some debugging which got left in. :-\ The movement keys now work as they should.
Quiet around here these days...
Dave