What is VdrAssistant?

The architecture was designed for distributed environments, with the requirement, that it should work the same, having all processes run on the same workstation or having each process run on a different workstation.

As Windows 7 is not a good environment for java applications, I had to create a new command center, which now runs in browser environments. The backend for the command center is a newly created Java system service. This way it is possible to manage VdrAssistant from Windows 7 too.

These where the assumtions made for developing of architecture:

• the VDR runs on a small (silent) machine, with small CPU-power
• valuable recordings are put on a storage system not being the VDR, especially if the VDR runs event triggered
• if that storage system is a NAS, the services of VdrAssistant should work on a different workstation with enuf CPU-power to perform a conversion of VDR-recordings into i.e. DVD format
• a desktop application should manage all working parts

The GUI-Part should run on any system, that supports a java GUI (tested only Linux and Windows), the services are designed to run on Linux-systems only (no plans to port them to other osses).

Supports all formats of VDR-recordings: PES, PES-HD, TS and TS-HD

The distinction works seamless from scanning to conversion.

• Overview of recordings whith the possiblity to change and manage cutmarks, rename or move recordings and to split or join them.
• convert VDR-recordings
• the conversion process is modular and configurable (but currently only DVD is a supported target format)
• Create menue templates for conversion process
• menue templates can be shared between different users. ThemeEditor and SkinEditor have an import- and export-function to support this.
• Show Epg-data on systems with timer triggered VDR, when the VDR is not running

The menue template where the main reason to start development of VdrAssistant.

I tried somewhat similar with vdr2iso, but I hit the limits of perl/Tk, so I decided to head redesign and reimplementation with Java.

The "professional" menu creation applications (well, those I know) only create final DVD-menues. I wanted to have menue templates like burn-plugin, where most texts where taken from VDR-recordings at conversion time.

But contrary to the burn-plugin, I wanted the templates be configurable - something between result from professional menu creation systems and the burn-plugin.

The menue templates of VdrAssistant are split into 2 virtual parts: Theme and Skin.
The theme holds the information, what elements form part of a template and where they are places and the order they form.
The Skin holds information about colors, fonts, border size and color, ...
Both together build the base for an image, which will be used as menue image. But this image is created at conversion time only.
Currently only the creation of immobile menues works. Animated menues are a big point on my wishlist.

As the DVD-Specs has lots of restrictions about the active menue elements (buttons), I abstained from them (at least from visible buttons) completely. So with VdrAssistant buttons could be created using all RGB colors with alpha blending and the don't have any restrictions related to size or position. So overlapping buttons can be created.

Result of all this is a Themen-Editor and a Skin-Editor.

The Theme-Editor is the drawing board, where the templates could be created.
Interactively using the mouse and context menue.
Elements can be added, moved around and removed.
... until you're satisfied.

The Skin-Editor offers the ability to change color, font and look of elements. Again interactively and visual. For better handling, I created 2 separated applications instead of a single one. So their windows can be arranged to support individual customs.

Even if I'm only interested into DVD as conversion target, I know, that there are and will be others. Recently I added recoding into mkv-containers.

So I designed the conversion process as a list of single steps, which are all configurable. The informations needed to perform a conversion is put into so called Jobs. That includes a list of VDR-recordings, a menue theme and a menue skin. Finally we need some limits for possible compression, the desired media type and last not least the format of the conversion target (DVD).

That leaded to the Job-Editor, usable to create and manage jobs and a Job-Processor, which carries out the defined processing steps. Both should be completely independant - i.e. it should be possible, to create new jobs, while a conversion process is running, without having to worry about a Job-Processor having completed processing and looking for new conversion jobs.

That food for thought leaded to the release system of conversion jobs. Jobs can be edited without any time limit. They have to be released to become visible for the Job-Processor, which locks a job before starting conversion process. The Job-Editor may also be used to watch the status changes produced by proceeding Job-Processor. Success or failure of completed jobs is signalled and a failed job may be released again to restart processing.

the comfortable job management rised the desire to have similar management for VDR-recordings too.

That was the birth of Recording-manager

The recording-manager uses handbrake to get informations about VDR-recordings.

As the Job-processor uses projectX for cutting, it was quite obvious to use projectX for management and controlling of cutmarks at desktop application too. You can start projectX from the context menue of the Recording-manager. VdrAssistant converts the cutmarks automatically into the format for projectX and adds parameters, so projectX shows the recordings right up and new cutmarks can easily be saved to the recordings directory.

With the time of using VdrAssistant I realized, that projectX is also very usable for quick snapshots from recordings, usable to be used at menue template creations.

Changed cutmarks from projectX could be saved as marks.pjx. That filename is the default for automated cutmark support for projectX cutmarks.

So if you save your cutmarks from projectX as marks.pjx, that cutmarks will be evaluated at next rescan of the recording. VdrAssistant handles both cutmark formats (timebase for VDR, byteposition for projectX). Use the context menue to import changed cutmarks (any filename and both supported formats) without the need to rescan recording.

Additional functionality worked out during time of usage:

• split VDR-recordings
• join VDR-recordings
• rename/move VDR-recordings
• recode VDR-recordings into mkv-container

The Epg-manager is the result of kidding around. I wanted to get into Java filters and bothered by the flushing advertisements and javascript restrictions of the well known epg-providers accessible via internet.

So I created an application, that shows epg-data (without any blinking and flushing ...). I added several filters and a powerful textsearch. The wish to be able to create timers rised by using Epg-Manager.

The birth of EPG-collector was also a bit later and emerged from the case, that my VDR is timer triggered and most time of day offline. In the beginning, the epg collector transferred files only. When I got the needed Java-knowledge, I changed that service to use the database and so reduce the load generated by VdrAssitants desktop application.