Raspberry PI3 + Raspbian Stretch + Sundtek MediaPro III.

    Hello,


    By advance 'Sorry' if the question was already asked, but I haven't found a solution and GoogleTranslate is not so good. I can try the English, but my native language is the French.


    My aim is to use VDR with a Raspberry Pi3, Raspbian Stretch and a TNT Tuner 'Sundtek MediaPro III' :

    http://sundtek.com/shop/Digita…T2-FM-Radio-AnalogTV.html

    I use LibreElec (OSMC), with the same hardware, but I like the look of VDR and I would have the possibility to edit the videos : cut the commercials per example.


    It's a fresh install of Raspbian used only for VDR. The licenses keys for MPG2 and WVC1 are active.


    I can have an image and the sound but the movement is very slow. The reading of a video file (MP4 ou TS) with 'Omxplayer' is good.

    The actions on the keyboards take a long time to be active. The Sundtek MediaPro III has a remote command, but it seems not recognized. The 'channels.conf' is good.

    The Xine interface seems not usable too ... The image and the sound are present but the image move by steps and I don't know how to change the channels.


    I have followed some links to install VDR under Debian with my Raspberry Pi3.

    http://support.sundtek.com/index.php/topic,53.0.html

    https://wiki.debian.org/VDR

    https://www.linuxtv.org/pipermail/vdr/2009-June/020740.html to modify the "~/.xine/config" and "~/.xine/config_xineliboutput" for adjust the buffers and the number of frames without visible results.


    The Sundtek MediaPro III's remote command is the number '3' :

    http://support.sundtek.com/index.php/topic,1121.0.html


    Bellow, you find my configuration.


    Again 'Sorry' if the subject is already treated in the German forum.


    Any help will be appreciate.


    Best regards.




    The last lines of '/boot/config' are :


    Quote

    dtparam=audio=on

    gpu_mem=128



    The Debian Raspbian configuration is the full version with the auto-login as 'Pi' user :

    The SD-card is a SanDisk 'microSDHC UHS-I' of 32 GB.



    The '/etc/hosts' file contains the following lines (extract) :

    Quote

    127.0.0.1 localhost

    192.168.1.02 rpi3.mydomain.org rpi3



    The service for the Sundtek MediaPro III (/lib/systemd/system/sundtek.service) contains :


    The service for VDR (/lib/systemd/system/vdr.service) contains :

    With the delay (--start) for the Sundtek's service, for the moment I make a 'systemctl restart vdr' when the Raspberry Pi is up.



    The installed packages for VDR and Xine are :


    The status for the services (systemctl status sundtek vdr) :


    An extract of '/var/lib/vdr/channels.conf' :

    Edited once, last by 74LS: Add an extract of 'channels.conf'. The link on the remote command. ().

    Quote from 74LS

    The Xine interface seems not usable too ... The image and the sound are present but the image move by steps and I don't know how to change the channels.

    xine/xineliboutput does not support the Raspberry Pi's hardware-decoder (several years ago someone attempted to write a xine plugin, but unfortunately the source code was never released: Rasperry Pi xine plugin).


    The rpihddevice-plugin is capable to use the hardware decoder of the Raspberry Pi - this ist the most recent commit: https://projects.vdr-developer…28b7109d931a7a19907a26037 - AFAIK this package is not part of the debian repositories - so you need to install vdr-dev (which contains the header files for the vdr) and the other build-dependencies and build it yourself - see https://projects.vdr-developer…ihddevice.git/tree/README for details.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Quote from seahawk1986


    The rpihddevice-plugin is capable to use the hardware decoder of the Raspberry Pi - this ist the most recent commit: https://projects.vdr-developer…28b7109d931a7a19907a26037 - AFAIK this package is not part of the debian repositories - so you need to install vdr-dev (which contains the header files for the vdr) and the other build-dependencies and build it yourself - see https://projects.vdr-developer…ihddevice.git/tree/README for details.


    Thanks for this explications. I am happy to see that I have not make a mistake :)


    Can I use the 'vdr-dev' package from de Raspbian repository ?


    Is it only the 'vdr-plugin-rpihddevice' to compile or is all VDR code that must be compiled ?

    Quote from 74LS

    Can I use the 'vdr-dev' package from de Raspbian repository ?

    Yes, this package is intended to provide everything needed to build vdr plugins with a "modern" Makefile, which allows building them outside of the PLUGINS directory of the vdr source code.

    Quote from 74LS

    Is it only the 'vdr-plugin-rpihddevice' to compile or is all VDR code that must be compiled ?

    Only the plugin has to be compiled. Its Makefile uses pkg-config to read the vdr build configuration (vdr.pc is provided by the package vdr-dev).


    IIRC newer Debian releases are using the ARGSDIR configuration method to enable and configure vdr plugins - in order to load the rpihddevice plugin you could need to create a file /etc/vdr/conf.d/50-rpihddevice.conf(which also can be used to pass additional arguments to the plugin):

    Code
    [rpihddevice]

    The plugin should work best without a running X server.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    I haven't used Raspbian for several years (I am used to Arch Linux ARM on my Raspberry Pi), but Raspbian lite seems to be a good starting point if you want to start with a minimal set of installed packages.


    Stopping/disabling the display manager should do the trick on a regular Rasbian desktop version (the systemd unit for the actual display manager should provide the alias display-manager.service) :

    Code
    # stop the display manager
sudo systemctl stop display-manager.service
# prevent the display manager to be started automatically
sudo systemctl disable display-manager.service

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Edited once, last by seahawk1986 ().

    I discover this with interest. I'm going to give it a try with the replacement of my LibreElec box.


    Do you know if the Sundtek's remote command is fully operational ?


    An interest, for me, to have a solution based on Debian, it's I can manage the RPI like my others computers. I can define the securities rules, add some packages, use GlusterFS (https://www.gluster.org/) directly because I have a GlusterFS cluster done with two RPI. If the CPU's load is low, I can expect to directly save the videos on the GlusterFs cluster without use a local storage - it must be verified.


    For an immediate solution, MLD has a big interest if I could use the Sundtek's remote command AND if I can edit the video to remove the unwanted parts.

    Do you know if it is possible ?

    MLD might be a convenient shortcut to get a (mostly) preconfigured VDR. Cutting recordings is a core functionality of the VDR and according the the GIT there is a preconfiguration for newer sundtek remotes in the dvb-sundtek package (http://www.minidvblinux.de/git…es.d/80-remote-eeti.rules).


    If you plan setting it up yourself, here is some background information on using the sundtek ir receiver with vdr on a Raspberry Pi:


    As far as I know the MediaTV Pro III only supports the NEC ir protocol (which is used by the included remote control).

    The Sundtek driver requires the kernel module uinput - which you might need to load using modules-load.d (if it is not built into the kernel) - and creates a kernel input device for the ir receiver.


    Basically there are two ways to configure the VDR to listen to kernel input devices:


    You could use a daemon like lirc (newer versions (=> 0.9.4) come preconfigured for the devinput driver - you might want to disable the included lircd-uinput.service, which creates a kernel input device itself and has a quite broken key repeat implementation), eventlircd (which you would need to build yourself for Debian) or inputlirc (which is in the debian repositories, but is somewhat broken at the moment: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879458 ) to translate the key events of the kernel input device into Lirc key presses. To enable lirc support you need start the vdr with the argument --lirc , e.g. by adding this line to /etc/vdr/conf.d/00-vdr.conf).


    Alternatively you could change the systemd unit for the vdr process to enable reading key presses from a tty - on my Arch Linux ARM installation I am using this systemd drop-in for the vdr.service to switch to tty7 before starting the vdr and connecting it to stdin:


    If vdr's remote.conf does not exist or does not contain entries for an available input method, vdr will start with a learning mode, which enables you to assign the keys to vdr commands.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Quote from berndl

    if you just want to have a VDR, why not giving

    https://www.minidvblinux.de/ a try? It works well with Sundtek sticks out of the box and has the rpihddevice already included. And it can be tested even without installing...

    Just a test this night. I've just a little problem, all informations are in German and I don't understand the German :(


    In "Live" mod I've tried "Kodi", I don't know if it's the good choice.


    I've tried with GoogleTranslate. Could you give me a link on the full documentation to use it with GoogleTranslate ?

    Quote from seahawk1986

    MLD might be a convenient shortcut to get a (mostly) preconfigured VDR. Cutting recordings is a core functionality of the VDR and according the the GIT there is a preconfiguration for newer sundtek remotes in the dvb-sundtek package (http://www.minidvblinux.de/git…es.d/80-remote-eeti.rules).


    If you plan setting it up yourself, here is some background information on using the sundtek ir receiver with vdr on a Raspberry Pi:


    [...]

    Thank you for this details Seahawk1986. I'll try to follow your advices after to have a VDR operational with the minimum of mandatory features.


    Just some comments.

    I've missed the option "--lirc" for VDR, it could be enough to use the Sundtek's remote when the file given by Sundtek for the remote is copied in "/etc/lirc".

    With the RPI and Raspbian out of the box, when the driver for the MediaPro III is launched, the remote command is actived even without the "lirc" package ...?


    If I don't give some new for a time, it is not because I give up to use VDR, but only because you and Benrdl give me a good list of things to do ! Thanks :)

    Quote from 74LS

    With the RPI and Raspbian out of the box, when the driver for the MediaPro III is launched, the remote command is actived even without the "lirc" package ...?

    Yes, it is an userspace driver which uses uinput to create a kernel input device for the remote (and the driver is able to decode the ir signals, too). If the vdr is able read the key events from stdin (e.g. by binding it to a tty) it should work without lirc.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hallo Seahawk

    Mein Ziel ist ein vdr für ein RP B+ mit selbst kompilierten rpihddevice mit Stretch. Bei start wird kurz ein grünes Kästchen mit no Channel Meldung gezeigt, gefolgt von ein rosa Kästchen mit Tag und Datum, und im Hintergrund werden immer noch log Einträge gezeigt obwohl auf tty10 in cmdline.txt angepasst. Aber Tastatur mit Remote.conf von ein anderen Rechner (x86) funktioniert nicht ☹️.


    Schöne Grüße

    Eric

    Quote from EricAmir

    Oct 6 15:02:13 raspberrypi vdr: [724] rpihddevice: MPEG2 video decoder not enabled!

    Wenn du keinen Key für den MPEG2-Decoder kaufst, wirst du mit dem rpihddevice keine SD-Kanäle wiedergeben können.


    Für die Steuerung über Tastatur muss du den VDR dazu bringen vom tty zu lesen und da es keinen X-Server gibt, sind das KBD- statt XKeySym-Tasten. Eine Beispielhafte Ergänzung für die Systemd-Unit hatte ich z.B. mal hier gepostet: [rpihddevice] Tastatur und X-Server

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hi Seahawk

    Nachdem ich die drop-in Sachen im post in /etc/systemd/system/multi-user.target.wants/Vdr.service konsolidiert habe lief Vdr nicht nachdem reboot. Ist das die richtige Vorgehensweise?

    Gruß

    Nein, bitte nicht blind darauf losbasteln, sondern die Dokumentation lesen:

    Quote from man systemd.unit

    Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section headers. For instantiated units, this logic will first look for the instance ".d/" subdirectory (e.g. "foo@bar.service.d/") and read its ".conf" files, followed by the template ".d/" subdirectory (e.g. "foo@.service.d/") and the ".conf" files there. Moreover for units names containing dashes ("-"), the set of directories generated by truncating the unit name after all dashes is searched too. Specifically, for a unit name foo-bar-baz.service not only the regular drop-in directory foo-bar-baz.service.d/ is searched but also both foo-bar-.service.d/ and foo-.service.d/. This is useful for defining common drop-ins for a set of related units, whose names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose systematic naming structure is built around dashes as component separators. Note that equally named drop-in files further down the prefix hierarchy override those further up, i.e. foo-bar-.service.d/10-override.conf overrides foo-.service.d/10-override.conf.

    In addition to /etc/systemd/system, the drop-in ".d/" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login