Beiträge von sirwio

  • vdr won't start with commit 00af2c0e of rpihddevice

    It was time to update my PI's. But I ran into some problems with commit 00af2c0e of rpihddevice!


    Staring with commit 00af2c0e my pi box/boxes won't start anymore. The previous commit (db7c53d) works.


    Code
    root@pi5:/usr/local/src/vdr# /usr/local/bin/vdr -w 60 -u pi --no-kbd --port=6419 -c /var/lib/vdr -P rpihddevice
Floating point exception



    This is on updated raspbian jessie with latest firmware


    Code
    root@pi5:/usr/local/src/vdr# uname -a
Linux pi5 4.4.26-v7+ #915 SMP Thu Oct 20 17:08:44 BST 2016 armv7l GNU/Linux
root@pi5:/usr/local/src/vdr# /opt/vc/bin/vcgencmd version
Oct 20 2016 14:57:49
Copyright (c) 2012 Broadcom
version b1f1c64dd836f2324e1105db36f8c356a11b2d54 (clean) (release)


    Regards,


    Magnus

  • [ANNOUNCE] CEC Remote Plugin 1.0.0

    While looping over the cec keys one loops one index to little in a few methods of ceckeymaps.cc


    This causes a problem for the Samsung specific cec code AN_CHANNELS_LIST with has the same value as CEC_USER_CONTROL_CODE_MAX (since its the last one defined in libcec).


    My Samsung remote does not have any suitable key to bring up the vdr menu. Hence I wanted to remap a key that was close to the middle of the remote and that was the Chanel List button...


    I have attached a patch where I have a suggested fix. While at it I would also recommend to remove the commented out code for the mDefaultKeyMap initialisation :)


    - Magnus

  • [ANNOUNCE] CEC Remote Plugin 1.0.0

    Hi,


    To bad I didn't have the chance to report this before the launch of 1.0.0. Been busy configuring a Raspberry Pi 2 over the weekend.


    I would really like to have an option to hide the cecremote menu from the vdr main menu. Similar as to what is available for multiple other plugins e.g. remote timers.

  • [ANNOUNCE] CEC Plugin 0.1.0

    Zitat von glotzipapa


    I can confirm this bug. I use libcec 2.2.0 und latest userland libs. Setting both device types will result in hanging startup.

    I have as well been using libcec 2.2.0 and has also tested with the latest git commit b3d938a5 of libcec.
    If i register the tuner prior to prior to the recording device it works.


    Unless there is a need for it I would suggest not announcing the plugins as both a recording device and a tuner device. At the end as I mentioned before the vompclient implementation settled to only register as a recording device. More info about the discussions that lead to that decision can be read here at the loggytronic forum.


    - Magnus

  • [ANNOUNCE] CEC Plugin 0.1.0

    With changeset 19 vdr hangs at startup. This is due to the change to announce oneself as both a CEC_DEVICE_TYPE_RECORDING_DEVICE and a CEC_DEVICE_TYPE_TUNER e.g. these two lines of codes in cecremote.cc:

    Code
    mCECConfig.deviceTypes.Add(CEC_DEVICE_TYPE_RECORDING_DEVICE);
mCECConfig.deviceTypes.Add(CEC_DEVICE_TYPE_TUNER);


    If I remove the second line the plugin works as expected for me.


    When we worked on the cec support on vompclient we also played around with announcing oneself as both of these types at the same time. I can't recall that one got any hangs and according to the CEC spec it is definitely valid to announce oneself as supporting both types. At the end Marten, one of the vompclient maintainers, decided to stick with only announcing vompclient as a CEC_DEVICE_TYPE_RECORDING_DEVICE.


    Still I think it would be of interest to support both types and change the "active" type depending on if one is watching recordings or watching live broadcasts. For me this would be nice since one of my TV's remote have the key CH+ and Skip right on the same button (and the same of course for CH- and Skip left). It would thus be convenient to have the CH+/CH- functionality while watching live tv and the skip functionality when watching recordings.


    -Magnus

  • [ANNOUNCE] CEC Plugin 0.1.0

    pugixml would work out fine for me as well. What one might consider is if the source code for it should be installed along with the cecremote plugin or not. This would solve the problem of distributions where pugixml is not available. The overhead would be minimal and the license of pugixml do allow such distribution since it has a generous MIT license.


    What I did on rasbian, who lack pugixml packages, was to create a pugixml folder in the plugin source directory and instead of linking with the pugixml library I instead link directly with the source code.


    - Magnus

  • [ANNOUNCE] CEC Plugin 0.1.0

    I have done some investigations on why the Stop key does not work as intended on my setup. Turns out the Stop key is interpreted as a combo key. If no other key is pressed within a timeout the key press will be registered by libcec.


    The timeout is configurable by setting iComboKeyTimeoutMs field of CEC:libcec_configuration. By default the timeout is 1000ms.


    The Stop key is prevented to be processed since there is a check for key.duration to be equal to zero. I am not sure on the best way to handle this yet. A dirty workaround is to check for:

    Code
    if ((key.keycode >= 0) && (key.keycode <= CEC_USER_CONTROL_CODE_MAX) &&
    ((key.duration == 0 || key.duration > 1000)))


    Hints are welcome to solve it in a more proper way.


    - Magnus

  • [ANNOUNCE] CEC Plugin 0.1.0

    I was a bit quick in mentioning that I could access the menu using the "Find" button on the remote. Apparently the "Find" button generate a CEC_USER_CONTROL_CODE_CONTENTS_MENU that is mapped to the Setup menu. Since the "Find" button is the only available button on my Philips remote i experimented changing the mapping to kMenu instead of kSetup.


    Also adding the a mapping for the press of the back button, CEC_USER_CONTROL_CODE_EXIT, to kBack made the back button functional.


    The following is the diff of the changes made:



    - Magnus

  • [ANNOUNCE] CEC Plugin 0.1.0

    I got the same segfault on raspian, raspberry pi, as well. Interestingly if I simply wait for the remote key learning to end the CEC functionality works surprisingly well.


    This is on raspbian with vdr 2.1.6 and changeset 18:20a5ba3bee27 of cecremote. The TV is a Philips.


    Most buttons on the remote work as expected. There are a couple of gotchas that I have encountered so far.
    The back button does not work... Kind of a showstopper but my workaround while I have time to troubleshoot it properly is to press the subtitles key. That will give the OSD message "No subtitles available" and will take me out of the menus!


    While watching recordings the Stop button does not work. Only way to end the recording is to jump to the end of the recording so that it ends and goes back to live mode again. This is slightly similar to problems I encountered with the cec support for vompclient. The solution there was to announce vdr as a CEC_DEVICE_TYPE_RECORDING_DEVICE instead of a CEC_DEVICE_TYPE_TUNER.


    I will continue my test and will also familiarise myself with the plugin code so that I can contribute.


    - Magnus

  • VDR auf Vu+ STBs (z.B. Vu+ Zero, SoloSE)

    Nano: Would it be possible if you could write a short summary in english summarising the content of this thread? My german is not as good as I wish it would be.


    About two years ago I made an effort to port and get vdr running on a vu+ ultimo. I have some success but got problems getting encrypted channels working.
    Did not spend time getting the OSD working but simply got it working as a streaming server.


    I posted this on the vdr mailing lists
    https://www.mail-archive.com/vdr@linuxtv.org/msg16940.html
    but there was no response on my post and since I did not get the encrypted channels working I ditched the idea. Now there appears to be some progress again... interesting.


    I would love to get vdr running on my vu+ ultimo that is equipped with three dub-s2 tuners. I still think it would be a energy efficient vdr server with an affordable price.


    - Magnus

  • Raspberry PI über CEC steuern

    I had the same problem initially. I previously had version 1.8.1-1 of libcec installed since this is the recommended version to use when compiling/running vomp. Since libcec-daemon requires a later version I installed version 2.1.0-1. libcec-daemon then compiled but did give an segmentation fault when executed.


    I then manually removed all libcec packages and reinstalled version 2.1.0-1 and the segfaults was then gone. Cannot be 100% sure that the segfault was due to different versions of the runtime and developer packages but it sure point in that direction.


    Zitat von francescosoft

    ich bekomme nach dem Make nur ein segmentation fault.


    root@raspberrypi:/home/pi/libcec-daemon# ./libcec-daemon -l
    Segmentation fault


    Hat jemand eine Idee ?

  • Raspberry PI über CEC steuern

    A can't get the libcec-daemon to be functional when its started as a daemon.


    This is on a Moebius Raspbian installation with minimal packages installed but I experienced the same on a standard Raspbian installation.
    The tests have been executed as root.


    I'm testing the remote using evtest started as:


    # evtest /dev/input/libcec-daemon



    If started with e.g.
    # ./libcec-daemon -vv -d


    The following is the output (with the output redirected to a file)


    TRACE - Main::getCecName()
    INFO - Opened /dev/uinput
    INFO - Created uinput device
    TRACE - Main::Main()
    TRACE - Main::loop()
    TRACE - Cec::open()
    DEBUG - Main::onCecLogMessage(1103 [D]unregistering all CEC clients)
    DEBUG - Main::onCecLogMessage(1106 [D]Broadcast (F): osd name set to 'Broadcast')


    It is like it is not getting a response from the TV.
    When started in non daemon mode it communicates with the TV and finally enters the libcec-daemon event loop indicated by the following on the console/file


    ...
    DEBUG - Main::onCecLogMessage(2738 [D]<< Recorder 1 (1) -> TV (0): vendor id Philips (903e))
    DEBUG - Main::onCecLogMessage(2740 [D]<< Recorder 1 (1) -> TV (0): vendor id feature abort)
    DEBUG - Main::onCecLogMessage(2741 [D]<< transmitting abort message)
    DEBUG - Main::onCecLogMessage(2743 [T]<< 10:00:8c:00)
    DEBUG - Main::onCecLogMessage(2985 [T]>> 01:00:8e:00)
    DEBUG - Main::onCecLogMessage(2986 [D]>> TV (0) -> Recorder 1 (1): feature abort ( 0))
    DEBUG - Main::onCecCommand(Command 0 to 1 0)
    DEBUG - Main::onCecLogMessage(2989 [D]marking opcode 'menu status' as unsupported feature for device 'TV')
    TRACE - Loop
    TRACE - Loop
    TRACE - Loop


    Any ideas?

  • [Prototyp] RPI Ausgabeplugin

    Fantastic work. Compiled vdr with streamdev-client and rpihddevice tonight and it worked surprisingly well. Fast channel switches and perfect picture quality on the channels (even though they are SD).


    Can't wait to follow this project in more detail. Next steps for me is to get a libcec-deamon working so that I can use the remote controller of the TV.


    Once again thanks for a very promising plugin.

  • [Smart TV] Tester für "VDR on Smart TV" gesucht

    The timeout of 1.5s is probably a good value for users mostly zapping between 1 digit number channels.


    While experimenting I noticed that while entering two or three digit channels its quite often necessary to take a glimpse at the remote to see where the next button is located on the remote. 1.5s is too short then but a 2s timeout would be sufficient and a good default.


    Did test channel swapping, between three digit channels, using my three kids of varying age between ten and nineteen behind the remote. Only one of them were able to change channels with the 1.5s timeout five times in a row. The two other kids only succeeded at about 50% of the changes with a bit of training. I personally have a bit higher success rate but have much more training with the user interface :)


    I can assume that the success-rate will improve if the initial (unnecessary press) is removed but still we all believe that a 2s timeout is an appropriate default.


    - Magnus

  • [Smart TV] Tester für "VDR on Smart TV" gesucht

    Zitat von thlo

    Yes, from implementation, a first number-key-press event brings up the fields to enter the channel number. The second number-key-press event is taken as the first input. I probably should change that behavior so that the first number-key is already captured and used.


    I would appreciate such change as well.


    One additional thing that I have found when entering two or three digit channel numbers is that the time before the entered digits are interpreted to be complete is a bit too short right now. A slightly larger timeout would make it easier for users with butter fingers.



    Regards,
    Magnus

  • gentoo-vdr-scripts and --epgfile default value

    I had some problems getting epg information for the whole week when I switched from a dvb-t to dvb-s2 system.


    What I found out was that no epg.data file was created and hence the epg information collected would not persist between restarts of vdr. It appears as if the default value used for --epgfile is -E-.


    According to Klaus in this mail thread:
    http://www.linuxtv.org/pipermail/vdr/2013-March/027481.html
    The -E- does disable the creation of the epg data file completely.


    The file /etc/conf.d/vdr contains the following help text:

    Code
    # VDR write the EPG default in the CACHEDIR
# overwrite this with following (no good idea)
# write the EPG data into the given FILE; use '-E-' to disable this
# if FILE is a directory, the default EPG file will be
# created in that directory
#   allowed values: -E-, file/directory names
#   default: -E-
#EPGFILE="-E-"


    Is the intended idea that by default there will be no epg.data file created? If thats the case I would expect it to be a good idea to overwrite the value of the EPGFILE contrary to the suggestion in the help that its a "no good idea"


    In my opinion a more userfriendly solution would be to skip passing the --epgfile parameter to vdr if EPGFILE is not defined. E.g. changing the line

    Code
    add_param "--epgfile=${EPGFILE:--E-}"


    to

    Code
    [ -n "${EPGFILE}" ] && add_param "--epgfile=${EPGFILE}"


    in file /usr/share/vdr/rcscript/pre-start-30-parameter.sh


    - Magnus

  • [Smart TV] Tester für "VDR on Smart TV" gesucht

    The clock is displayed correctly on my tv.


    The channel numbers are displayed correctly but fails to display numbers that are three digits long e.g. channel numbers >=100


    I also experience an odd problem when choosing a channel number from the live tv list using numbers on the remote. When digit 1 is pressed I get an an "e" in the inputbox. If 2 is pressed i get an "b" in the input box. Succeeding presses after 1 or 2 has been pressed result in proper digits displayed but the channel will of course not be found since it starts with the letter e or b.
    Any other digit pressed first gives correct behaviour. I can e.g choose channel 12 by pressing the sequence 312 but sequence 112 will fail.

  • Vomp Version 0.4.0

    I had some trouble getting vdr-vompserver 0.4.0 to emerge as well against vdr 1.7.36. Had to patch the vompserver makefile. Did not get the same errors as you observed thought.


    Please see attached ebuild and makefile patch. Have mercy with the ebuild. I'm not very experienced in writing ebuilds and there might be better ways than having to apply the makefile patch.


    hd-brummy: I would really love to see the vompserver ebuild in vdr-devel...

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Thanks that worked much better. The vdr log now tells via the CAM that I need to stay tuned to the encrypted channel for up to two hours so that the service provider can send an update to the ci card.


    Btw - Is it possible to redirect the other inputs as well to the same CAM e.g:


    Code
    echo "00 02" > /sys/class/ddbridge/ddbridge0/redirect
echo "01 02" > /sys/class/ddbridge/ddbridge0/redirect


    Any trick to automate this at startup to the system so that its possible to get a reboot of the system a bit more wife friendly?