It's been a while since the last release, it's been a while since I could remember what I am supposed to be doing / would like to do for the next one. If you have posted here or emailed me about something you want doing to VOMP could you please make sure it is in the SourceForge bugs / request for features system - I try to use that as my definitive list of stuff-to-do. Thanks!
And to keep you updated, stuff that is already done for the next release:
BOOTP/TFTP support built in
Server names rather than IPs in "choose a VDR server" if you have multiple
A font problem with displaying accents is fixed
Timers list and view timer
Stuff I want to include:
Set timer from EPG
A choice of large or small network packets (make it work on lans and wlans ?)
Some other things I have forgotten (see above!)
Then for the release after that:
OSDs on recordings thanks to recent works with MPEG timecodes
Maybe include a TS demuxer in the client to speed up live tv and simplify the vdr plugin
Hi Chris,
i am really looking forward to the next version of vomp! The new features sound great!
As I think most of the important features are done (with the exception of a recordings-osd/statusbar - that would be great!), perhaps you should do a bugfixing-version, with these annoying things:
Sometimes Audio/Video-Asynchronism in LiveTV, (issue in the basic of mpeg-streaming?)
crashes of vdr or vomp (sometimes we have to restart vdr one time a day...), (not complete sure what are the single reasons, one is this: http://sourceforge.net/tracker/index.php?func=detail&aid=1398901&group_id=139484&atid=743655)
missing backward-scan (http://sourceforge.net/tracker/index.php?func=detail&aid=1226443&group_id=139484&atid=743658)
and i still have sometimes comp-crashes when trying to access a not reachable channel...
I would recommend to start with debugging/completing the already good featureset, before adding more new features.#
I know that it is more fun and motivating to add new functions, but now should be the time to make the existing features perfect!
Schnurps
One thing regarding the rebooting of the VDR: it would be nice to be able to do just that from the box, i.e. send an SVDRP command to the VDR box to try to get it to restart.
rgds
posde
One more suggestion for future releases:
A Skinning-System for VOMP!
Would be nice to have the possibility of individual skin for every single mvp.
I like this functional and basic skin (because it is really fast), but perhaps somebody wants to make another skin, more likely looking like Windows MCE/Meedio with more and larger icons etc.
Schnurps
posde: Do you mean restart the MVP or the VDR software/box?
Schnurps: Yes, I had wondered when skinning would come up ;) Currently I don't know about that one, and am inclined to leave it a while until I have a few more things working. I agree it would be nice, and I do intend to make the current interface a little more graphical when I get a proper icon drawing system in it.
Certainly changing all the colours would be fairly easy now.
many thanks for the 0.2.0 Chris!
WAF has risen 2 points with your new release ;).
Quote
[...]
Restart VDR and see if it works...
it DOES !!
one minor note:
- leaving a config sub menue should exit to config main menu
cheers
Harry
Quote from: Chris on February 27, 2006, 19:29:59
posde: Do you mean restart the MVP or the VDR software/box?
VDR software.
rgds
posde
Quote
another minor here:
the german KiKa (a kids channel) stops broadcasting at around
9 p.m. or so.
tuning into KiKa after 9 makes the MVP hang.
it then needs to be power cycled.
can anyone from germany confirm this?
KiKa hangs for about 5 seconds, and then there is shown a KiKa-picture that give me exactly this iformation (Kika ends at 9pm).
But I have problems with unavailable/temporaly not-available channels, too.
I am using VDR 1.2.6, and because of teh missing auto-pid I have quite often wrong frequencies for updated channels...
Schnurps
Hey Chris, after many tries and errors i am now able to compile vomp for my surroundings.
Thank you very much for your great work !!!!
as a suggestion for the future releases a pin secured children protection system could be a good idea
and videotext on VOMP also.
Again thank you very much.
Lodda
@Lodda
Glad you have got it working. With the new built in Bootp/tftp servers or other?
Anti-child systems have been suggested before, but I have to admit - it's not high on my priority list.
@Schnurps
I know you have reported this a lot already, but if you have any more really detailed info about this I would be glad to hear it. It's the next thing on my list.
@Harry
I wondered about how to leave the config menus, but I thought it is unlikely that you would want to visit two in the same go. However, now I have used it for a while it is a bit unintuitive. What does everyone think?
What is your WAF scale like then? What level was vomp at before and where now? ;)
with a growing number of settings, categories surely are a good
idea; accompanied by a good (in terms of simple) handling routine.
my WAF scale ranges from 0 to 10 ... you've just hit 8 ;D.
...funny... sometimes WAF is explained as "Women's Acceptance Factor"
then sometimes as "Woman Acceptance Factor"
or "Wife Acceptance Factor"
cheers
Harry
hmmm...
is it just VDR 1.3.37 or me or the progressbar incorrectly calculating the
playing time?
quite often, the time indicator beside the progress bar claims the running
recording to be longer than it actually is.
can anyone confirm this?
cheers
Harry
Quote from: Harry on March 13, 2006, 19:56:18
hmmm...
is it just VDR 1.3.37 or me or the progressbar incorrectly calculating the
playing time?
quite often, the time indicator beside the progress bar claims the running
recording to be longer than it actually is.
can anyone confirm this?
I don't see this with vdr 1.3.44. The only oddity I see is that when I start playing a recording the time display is blank, the correct values are only shown after using one of the skip buttons.
(This is with today's CVS btw, not the latest dongle.)
Dave: It is supposed to show "-:--:-- / -:-:--" for the first second or two, but it should show numbers before disappearing even on the first play. Are you getting the dashes or is it totally blank?
Harry: Are you just seeing the lenth of the programme + start margin + end margin? If not, how much is it out by?
if i could only use the screenshot function within VOMP
found it in the source but couldn't make out how to shoot a photo :(.
tell you what: i'll shoot a picture of the distorted progress bar tonight
with my digicam if necessary and post it to the board.
- the picture is gonna tell you more precisely what's going on. :D
Quote from: Chris on March 13, 2006, 22:09:26
Dave: It is supposed to show "-:--:-- / -:-:--" for the first second or two, but it should show numbers before disappearing even on the first play. Are you getting the dashes or is it totally blank?
Yes it does show dashes rather than complete blank. And if I watch very carefully the dashes are replaced by numbers at the same instant the display disappears...
right then...
i think i've found something concerning the progress bar.
pic 01 shows the start of a recording...(everything's still fine)
after a couple of seconds the progress bar gets
confused ...see pic 02.
it MAY have something to do with VDR strangely splitting
the recording. see the files from the recording in my
filesystem in pic 03.
so it's unlikely me ;)
There is a bug reported on vdr-portal (http://www.vdr-portal.de/board/thread.php?postid=438886#post438886):
Vomp seems to crash while trying to access a corrupted video file.
(means that the linked video files are not available/accessable).
Cannot say anything to that, just want you to know, Chris/Dave! :-)
Schnurps
There is a known problem with reading timestamps from the video stream. Sometimes the VDR recording includes data that looks like a video timestamp, but it isn't. This shouldn't happen. I'm investigating and thinking about the best way to fix it, or work around it.
Harry: this is probably the cause of your weird display, and it could be to do with the way VDR has split the files, or just corrupted data in the file. Would it be possible to give me access to the 001.vdr file and the first 4 megabytes or so of 002.vdr? If you don't have any webspace where you can post it then you can email it if you like, provided it's only 8 MB or so:
m dot calderbank at iname dot com
MarkC
hi Mark,
i don't have access (yet) to my linux box from the internet
but will post the requested data ASAP.
thanks 4 your help!
Harry
[edit]
misspelled your name
[/edit]
Thanks Harry, I received your vdr files.
This is a different problem. Here, the actual timestamps transmitted by the TV station "jump" during the recording. The jump happens when "Hamburg Journal" starts and the music changes. This is also why VDR has split the file into pieces. If you play 002.vdr in mplayer, for example, you'll see that it starts at this point.
I'm guessing that 003.vdr starts when "Hamburg Journal" finishes, and then the timestamps are back in the original sequence. So the total length is correct when you play it, because vomp calculates the length from timestamps in 001.vdr and 003.vdr.
We assumed that timestamps would always be continuous, but it seems that some TV stations don't work this way. Have you seen things like this on recordings from other channels?
Mark
thanks for looking into this!
the thing is... this particular channel broadcasts different programs
for different regions during certain times.
that's why the picture changes so suddenly.
same problem on other channels?
will check tonight!
cheers
Harry
The pts and dts on DVB transmission are on most channels not continous. All DVB player application look with there is a big jump in the dts pts and, if there is a big jump, they correct the PTS and DTS appropriate.
This is why vdr uses internally the frame number in the cIndex class for calculating the current timestamp.
Why didn't you use for getting the length of the recording at the server side a call to cIndex member function last, which returns the total frame number and divide it by 25 (PAL) or 30 (NTSC) to get the totallength in seconds.
Marten
I will change the code so that it works out the total length from the last frame number. However that doesn't solve the problem of working out where the current playback point is in the recording... At the moment the exact timecode is retrieved from the MVP hardware, but that obviously isn't very useful if the stream PTS jumps about.
Well, just ignore too big changes in the jumping PTS. Look on sourceforge at Project guliverkli, then in subversion at file
/trunk/guliverkli/src/filters/parser/basesplitter/BaseSplitter.cpp
Function CBaseSplitterOutputPin::DeliverPacket, it is from a windows demuxer, who can also handle DVB TS Streams. You see if the change between to PTS of two successive PES Packets is too big, it just subtracts these Jump in the PTS. REFERENCE_TIME is pts*10000/90, see /trunk/guliverkli/src/filters/parser/basesplitter/BaseSplitterFileEx.cpp function Read .
In this way playback of transport streams is synchronized, maybe you get a timecode from this. Maybe you can store also for every second or every I-frame (I think one second accuracy or per I frame is enough for the progress bar) the pts together with the framenumber from cIndex and than if you get the pts from the hardware look into the array, which framenumber it is.
hi Mark,
i seem to only have tested my "Hamburg Journal" recordings ::)
because all my other recordings are fine!
(checked 4 different recordings from 4 diff. chans)
if it's too much trouble @debugging... i can live with the jump in time.
greetings
Harry