Topics

Vomp For Windows 0.2.7-3 is available for download. It corrects the following problems found after the release of 0.2.7:

* A crash in the options screen
* A problem with selection of video filter

A long time in coming, here is 0.2.7:


New Features

• Media player ! Supporting MP3 and JPG files
• For fast forward scanning, a slight jump back now occurs when the user presses play
• It is now possible to key a channel number in on the channel list page
• Current time indicator on EPG behaviour changed
• New options screens to allow for more, and better organised options
• Delete VDR timers now possible
• Programme summary during recording playback
• WOL support to wake up VDR server
• Variable width channel numbers supported
• Audio channel selection on Live TV
• Crash restarter - _some_ crashes are the code's fault - vomp will restart
• User configurable / assignable remote control buttons (omitted from first announcement! Oops, sorry Marten!)

Under The Hood:

• New GUI code. An overhaul of the design. Facilitates the new options screens, and maybe more in future
• Code updates for VDR 1.5 compilation support and GCC 4.2
• ticonfig included from MVPMC - a component for wireless MVPs

Fixes:

• A crash exiting recording while bar being displayed
• Radio EPG now shows radio channels
• Setting a timer just after midnight for a program starting around midnight bug fixed
• Fix for bootp serving IP when it shouldn't

Windows Client:

• ac3 sound support
• Code updates to make media player work on Windows

The Windows version is now available, thanks to Marten.

Credits:

Thanks goes to all in the credits file (in the source code), but specifically for this release: Andreas Vogel for the media player component, Marten Richter for making it work in Windows, Matthias Haas for WOL support and everybody else I have missed or am forgetting for the many bug reports and patches.

Two bugs that came to light with the build script v4 and have been fixed:

* crosstool was rejecting gcc 4.1. Using gcc 4.1 seems to generate a working cross compiler so it has been modified to allow gcc 4.1. Thanks to carsten for working on that.
* The kernel is built with a different version string to the one Hauppauge use meaning that insmod has to be given the -f switch to load the modules. -f was missing from the insmods script in the NFS root development file system tar. Fixed.

Issues to consider when developing for vomp...

I think it's great that people are working on things for vomp, but I need to do something about these monolithic patches containing several different additions or changes turning up that are near impossible to integrate into the codebase. So...

1. I am swamped with patches for vomp. It is safe to assume that if you create a patch for vomp it will not be included in cvs any time soon.

2. Smaller patches that do a very specific change are good - especially with an explanation.

3. Anything that runs straight on top of the current code is more likely to get a good reception - e.g. a new V* view class that does something but doesn't change anything else in the code.

4. Patches that change code in the base classes (e.g. surface, box, view, timers - the low level stuff) are likely to get a bad reception. To include these I have to read them very carefully to find out what they do. My time is limited as is everyone's, and frankly I would rather be working on my list of things to do for vomp rather than attempting to understand everyone else's. (Currently I spend most of my vomp time reading patches rather than coding things I want to code). If you need things changing in the base classes maybe it would be better to seperate them from your main code and submit bug reports or feature requests...

5. Patches that include patches from other people are bad. I probably already have that other patch on my to-do list, and having another patch file with that code included makes things really tricky. Especially if you don't even mention it is there.

6. I am trying to work through the patches in chronological order. This means that earlier patches will be easier to go through, but later patches won't because the codebase might have changed too much before I get to them.

Now I don't mean to put people off coding for vomp, but I would still like to be able to code for vomp myself which means I have to understand the code and keep it on track.

I realise it's going to be more difficult to code for vomp like this, but what I have to do with two monolithic conflicting patches isn't difficult, it's impossible...

For people with development environments set up:

Please could you download and test the current CVS code, I have made some small but major changes to the way that the timers module works and it needs some testing. It seems to be working quite well here (I'm surprised) but it could do all sorts of crashing or more likely freezing / hanging in situations I'm not putting it in.

If it's all working it will certainly fix a segfault crash that I found and may well allow the GUI to be a bit more responsive in some circumstances.

The segfault that it fixes occurs if you press back to leave a recording when the blue timer bar is being displayed - and you time it exactly right with a clock update (5 per second, so it did happen sometimes).

There is a new automatic build script released along with new build packages for various components. To build a development environment matching version 0.2.6 onwards, start here: http://www.loggytronic.com/vomp-devenv.php

Here is version 0.2.6, an even more experimental release than usual...

Visible changes:

* Support for wireless version of MVP (but only when wired...)
* Cutting marks support (thanks to macfly)
* Pressing OK on empty list crash fix
* Recordings sort order - you can now select the default sort order in the options. You can also change it temporarily when looking at the list by pressing the left or right arrow buttons on new remotes
* Translation text updates (thanks to all translators)
* In the windows client - mouse support and bug fixes

Non-visible changes (and the reason for the long release time)

* Major design change for live TV, TS demuxer moved to MVP, server plugin much simpler and cleaner. This will facilitate new features in future
* Cross compiler upgrade to crosstool-0.43 and gcc 3.4.5
* Kernel upgrade to 2.4.31 for the MVP dongle
* All new build scripts

Notes

* The standalone mvprelay program is not required for booting the H3 MVP
* Windows version known bug: Resets mute state and volume settings after channel change or navigation inside recordings (will be removed after version 0.2.7)

Things that didn't make it to 0.2.6 but are at the top of the list:

* Audio channel selection for live TV
* Wireless support for wireless MVPs
* ...and everything else...



p.s. The makedevenv script is now totally out of date and won't produce a working system. I will update it soon.

Vomp For Windows is released, read about it and download it here:

http://www.loggytronic.com/vomp.php#vfw

Yes, you see it correctly, version 0.2.5 is really released, it finally exists, yay, thank <insert relevant deity here> for that.

New Features:

• Fast backward scan. Fast forward has also changed to suit, there are now 4x, 8x, 16x and 32x in both directions
• Audio channel selection (currently works on recordings only). Press green while watching a recording
• Some changes to the OSD when in chasing playback mode. You can see how much of the program is yet to be recorded
• WSS (wide screen switching) - the non-SCART method (PAL only at the moment)
• Vomp now listens on a UDP network port and can receive commands to virtually press remote buttons

Fixes:

• Radio playback now works
• More demuxer / timecode fixes to improve and correct OSD time clocks
• Sub option screens now go back to the options menu
• Language translation updates
• Untested, but there is an update for compiling the plugin on 64 bit systems

News on Vomp For Windows:

• With old statically linked code now replaced with alternatives, the GPL licencing issues are now resolved and we can go ahead with the release of Vomp For Windows. However, due to the new code we are still ironing out the last few issues. It will be available for download soon.

Real life, large changes to the code in several places, necessary demuxer changes, but mostly real life were to blame for the very long wait for this release. It should all speed up again now.

Of course there are many things that did not make it to the 0.2.5 release. Most notably (and these will be included in 0.2.6):

• Support for H3 wireless MVPs
• WSS for NTSC
• Ability to delete timers

These things and possibly others will be in the next release. I also hope to go scanning through the forum and start applying patches that people have contributed (sorry to all who have written patches I haven't yet included).

To NTSC users:

How is the placement of on-screen items on NTSC? I am trying to make vompserver adjust to both systems and look as good as possible in both, but I am finding NTSC tricky as things don't appear on screen where they maybe should. Specifically, when you show the OSD bar on a recording does the current time on the right fit on the screen or does it go off-screen to the right?

Ok, I'm getting back into vomp properly after a very different summer. As for the forum over the last couple of days, well... My hosting provider informed me they were going to swap servers (with no downtime, ho ho), and then proceeded to delete all the loggytronic.com DNS records. So, having got that sorted I found out that the directory structure on the new server is different to the old - and SMF doesn't react well to that at all. So, I think it should be ok now after a bit of database tweeking, but if you see any errors let me know.

I/we are working on version 0.2.5 which will have any bugs we have fixed since 0.2.4 and there are quite a few I believe. (A new) fast forward and fast backward are done (pending some minor mods). PAL WSS wide screen switching is done (finally I get to have auto wide switching too). The MVP now listens on a UDP port and can take remote-button-presses by simple packets (email/forum me if you are interested and I will provide specs). There are also some hefty general code changes in the way the thing works, including a way to get more information about recordings than it got before, meaning minor improvements in chasing playback, summary information, audio channel selection, etc. Some of these have been worked on, some are still waiting to have the new information used properly. The big thing left to do before 0.2.5 is radio support which has been broken for far too long.

Anyone that thinks I should have replied to their thread on here and is still waiting for a response, yes, sorry I will get to it soon.

For anyone interested, the screenshots page is now updated to include:

• new welcome screen
• timers list
• set timer from EPG
• recording playback OSD

Bug fixes:
Bad navigation using skip buttons on recordings with PTS jumps fixed (skip buttons not behaving as they should)
Recording playback progress bar drawing the bar over the end fixed
Compilation bug for VDR 1.2.6 fixed
Compilation bug for server plugin on 64bit platform fixed
Client freezing when no stream is available fixed

[Please email]

As you may already know, Marten has been working on a Windows port of the vomp client. It is nearly finished but we have hit licencing problems. The binary executable cannot be released under the GNU GPL as everything else is, because part of DirectX (which is a non-GPL component) is statically compiled and linked in to the executable. However, as I understand the legal situation (and please debate this because nobody is 100% clear on this..), the copyright holders for vomp have the legal right to use their code that they have written for vomp in a different closed source proprietary project. Currently I believe this is how vomp for windows could be distributed - it will have a difference non-free licence. If anyone has had similar problems before, or knows or solutions, please do tell.

Anyway, the point is that technically I need the permission of all the copyright holders for vomp to use their code in vomp for windows. Looking at the CREDITS file (which may be missing people, if you have contributed anything and are not in the CREDITS file let me know) - I need the permission of the following people:

Mark Calderbank
Dave Pickles
Brian Walton
André Jagusch
Lars Fredriksson
Pák Gergely
Kimmo Lahdensivu
'jtk'
Marten Richter

Please email me your permission, and optionally post it here as well.

There are still things left to resolve even if all these copyright holders give permission.

Version 0.2.3 is now released.

But don't get too excited, this is a release because if I left it any longer I would forget how to do it... There are good points and bad points about this release, but since 0.2.2 was getting so long in the tooth I decided to move things along a bit with 0.2.3. So here goes...

Bug Fixes:

• The aspect ratio of video playback is now only changed after 3 consecutive identical signals in the stream, this avoids dodgy aspect ratio changes
• In recording playback a key sequence caused wrong results or lost audio, I forget which. It's fixed now anyway
• Vomp will now refuse to delete a recording that is still in progress
• EPG duplicate data rows bug fixed

But best of all ...........

• Audio / Video syncronisation is fixed!
• Live TV prebuffering now works

New features or changes:

• Vomp will now report failure to delete a recording and not remove it from the client GUI
• The server plugin should now trigger a recordings list update for the main VDR after a delete (I think this works?)
• TFTP default dongle file name changed to help deb packaging
• The server plugin now accepts the -c switch to modify the config path (like some plugins do)
• Client now supports multiple directory hierarchy levels for recordings
• It is possible to move recordings around the directory hierarchy (beta feature, careful with this! success/failure reports welcome)
• Many many code changes for portability

And now for the things that should be finished but aren't:

• Odd behaviour with PTS timecode jumps (timecode holes in recordings. jump keys start behaving very oddly)
• Radio playback navigation still broken
• Widescreen switching by WSS signal

So, the good points really are that a/v sync is fixed, prebuffering works, the multi directory levels for recordings, and moving recordings. The bad points are that radio navigation still doesn't work and PTS timecode holes still cause problems. Sorry to people waiting for these things to be fixed, they will be for 0.2.4.

One reason for why it has taken so long for 0.2.3 to materialise is that there has been massive code changes going on that don't result in any immediate visible changes, the code has been upgraded to support the Windows version of the client, which is nearing release so I hear...

In real VDR, is it possible to move a recording from one directory to another using VDR and the remote? i.e. not doing it yourself on a command line or something.

I just bought a widescreen TV, only to find that vomp doesn't seem able to tell the TV to switch aspect ratio... Anyone else with wide screen switching problems?

I have had a go at creating a script to do most of the work involved in creating a development environment. It should set up a directory structure and download and compile all the tools required to either use vomp over a NFS root or build dongles. The only things the script doesn't do are: Set up your DHCP/TFTP/NFS for NFS root development, and the final dongle build creation (since you need a Hauppauge dongle to do it).

Make sure you execute this script in an empty directory!!!

As long as you have C/C++ development tools, wget and bzip2 installed this script should work. I have tested it on Debian Woody and Sarge, Ubuntu Breezy and Fedora Core 5.

Please post success and failure stories to the forum so I can improve the script.

Bug fixes:

A couple of segfaults to do with backing out of  a recording playback by pressing ctrl-c on the console have been fixed. These would probably only show up to a developer but it was just possible one of them could occur when pressing back on the remote.
Fixed VDR crash when VDR cannot provide summary for recording (using 1.3 recordings with VDR 1.2, or perhaps even an empty summary file).
Fixed crash when tuning to off-air or non existant channels. You will still have to wait for the 20s timeout, but it shouldn't die anymore.

New features:

Mark has provided me with some new demuxer functions, leading to:
OSDs on recordings with times and progress bar... (alpha blended...)
Skipping by +/- 10s and +/- 60s are now exact, rather than the guesswork it did before.
And finally, client side connection loss detection.

This is a minor update mainly to fix compatibility with VDR 1.3.44. The files are under the "latest" section on the vomp web page:
http://www.loggytronic.com/vomp.php

Bug fixes:

Removed references to summaries on timers to fix compatibility with VDR 1.3.44
Fixed selecting the TCP window size in the client (I swear this worked when I originally tested it  )
Increased the timeout in the server plugin for acquiring live TV data from VDR