Hello Spirou,
It is perfectly feasible to have both versions complied and test the newer 2.3.1 gradually until you are happy to have it run at boot by default instead of 2.2.0.
It may be a little unconventional, but given your situation this is how I would do it in brief terms. You will need to do a little background reading and may need to adjust the below to suit your linux flavour.
1. Create a new directory called "opt" under the top level mount point i.e. # sudo mkdir /opt
2. Create a sub-directory in this /opt folder called "vdr". I usually grant this folder permissions 777 temporarily so I can play till my hearts content with having to keep issuing sudo. If security is a big issue for you, ensure you revert the permissions back to suit.
3. Download the source code for vdr, both 2.2.0 and 2.3.1 and extract to the /opt/vdr/ directory.
4. Configure both vdr versions utilizing the make.config vdr file to adjust the hierarchy folder structure to suit each version and your preference. For simplicity, on your first trial, I suggest using the option and hierarchy of the "one directory" approach i.e. make a folder called "1.ONEDIR" in both /opt/vdr/2.2.0/ and /opt/vdr/2.3.1/ and point each relevant make.config file to suit.
5. Issue the make command to both vdr versions (observe any options in the make command that vdr may expect i.e. ONEDIR=1 LCLBLD=1).
However, hold back the command # sudo make install. We will simply run the vdr programs from their local build directories.
5. Observing your preferred vdr make.config folder hierarchy as compiled in step 4, locate all your current vdr 2.2.0 config files that have been installed and modified via your repo install. The command #
whereis vdr will help you track these config files down. Once found, copy these to your vdr 2.2.0 hierarchy folder structure you chose in step 4.
6. Download the source code and make a symbolic link for your required plugins to the correct folder i.e. /opt/vdr/x.x.x/PLUGINS/src/ (replacing x.x.x with each of your vdr versions you are using/testing). NB: Some git repositories for plugin source code will have multiple branches for each vdr version. You will need to switch branch before compiling. Furthermore, some plugins, like vdr-plugin-live have dependencies, ensure these are installed via your package manager i.e. apt-get. TIP: vdr is shipped with a handful of exemplar plugins, these plugins source code can be deleted if you wish to keep only the plugin source code you want.
7. Invoke the make plugins command at each vdr version source directory to build your plugins (again observe any options in the make command that vdr may expect i.e.# sudo make plugins ONEDIR=1 LCLBLD=1).
8. Test and play. Stop the vdr version 2.2.0 that has been installed via your repo i.e. # sudo service vdr stop. Enter your compiled vdr 2.2.0 directory i.e. cd /opt/vdr/2.2.0/ and issue command # .vdr -Px -Px -Px (replacing x with plugin names you have made). Provided you have copied your configuration files (check permissions of these copies please!) from step 5, this instance of vdr should run exactly as your repo installed version. Once happy this is the case, change your initd/systemd/upstart (linux flavour and version dependent) to run vdr from /opt/vdr/2.2.0/vdr on boot.
9. Test and play with 2.3.1, copying configuration files between 2.2.0 etc as you describe, all in the name of fun! Best thing about this is if it all goes wrong you can simply delete the /opt/vdr/2.3.1 folder and start a fresh. Remember only one instance of vdr can utilize your hardware, so you will need to stop whichever vdr version is running before running the next - be mindful of recordings or people watching liveTV; they will be interrupted once you stop vdr. Best therefore to test when nobody is around and no scheduled recordings are imminently pending.
10. Once happy with vdr 2.3.1, alter your initd/systemd/upstart (linux flavour and version dependent) to run vdr from /opt/vdr/2.3.1/vdr on boot.
11 (optional) . As new vdr versions and plugins are released you know how to test without effecting your current build. TIP: this method can also be used to test latest source code of Kodi too. Simply make a folder /opt/kodi/ and download source and build. NB: be mindful of your .kodi file in your home directory. Best make a backup
I hope this helps you out.
Many thanks,
Guy
