Author Topic: vompclient 0.5 features  (Read 201 times)

Offline ralph

  • Jr. Member
  • **
  • Posts: 7
    • View Profile
vompclient 0.5 features
« on: March 11, 2018, 19:59:35 »
Hi vomp developers,

I just noticed that there has been a new release of vomp for RPI. Thx a lot for that :D. I am with vomp since more than 10 years now and it is still the best vdr streaming solution out there.

I tried to find answers to various question about the release but it is rather silent around vomp nowadays. I checked vdr-wiki, vdr-portal and the git for information. It seems most people rely on Kodi, which in my opinion is not suitable for the performance of a RPI. I also checked the git logs and got some ideas, while I am unsure in some aspects. Perhaps the developers would like to give some information on the release:
 
  • Is lirc supported now? I was using the lircd creating uinput events, but this also caused the console to show a lot of strange characters. Direct usage of lirc would be the better solution imho. CEC is not working for me as my TV does not support the forwarding of remote control events.
  • Is it possible to compile on Raspbian Stretch? I saw some commits regarding stretch, but is it working ootb with updated CEC and FFMPEG versions?
  • Is the server plugin also working with vdr 2.3.x? Latest Ubuntu versions seem to ship now with 2.3.x. Any experiences?
  • Is it planned to provide some information at the vdrwiki, in the vdr portal or at least as a readme? The marketing of vomp is rather modest. Or are no new users wanted?
  • Is there a chance to get a Debian package being built? The debian tree is currently reflecting the version 0.4.2 as head. Perhaps this can be updated. Also, the system integration is based on init and not systemd. This is a little outdated for jessie and stretch. Are there somewhere updates around already?
  • Are contributions welcome? In which way? I did not see the possibility to add myself as a developer. At least at the packaging point or by writing a readme I should be able to contribute a little.
  • Is root really needed to run vompclient? I was running vompclient 0.4.1 always without root and never observed any trouble.

Thx for any further information provided.
« Last Edit: March 11, 2018, 20:13:34 by ralph »

Offline Chris

  • Administrator
  • Hero Member
  • *****
  • Posts: 537
    • View Profile
    • Email
Re: vompclient 0.5 features
« Reply #1 on: May 09, 2018, 15:07:04 »
Hi ralph, it's good to hear from someone still using vomp! Now if only the forum notify system had worked it wouldn't have taken me so long to read your message... Oops!

I have just tried to compile vompclient on a fresh Raspbian Stretch and yes, you're right it needs some attention. It is possible but really the downloads and documentation need updating to support it OOTB.

So, in answer to your questions:

1. How you describe is exactly how I use vomp - lircd with uinput events. Since I don't use that Pi's console for anything else, vomp is always hiding the login prompt with the strange characters so it's not really a problem. The strange characters are caused by the kernel's /dev/input system taking the characters that lircd-uevent gives it and handing it to the console as keyboard input. Since the remote buttons are never going to get past the login prompt it's an ignorable problem... Having said that I did once have a quick look into whether it is possible to have the kernel be selective about which input devices it uses for console keyboard input but I didn't find a way. Perhaps there is a way to "consume" the key press... Maybe a bit more digging around would find a way. I would rather not change to support lirc directly because the current system of using /dev/input enables lirc, USB IR receivers and real keyboards simultaneously.

2. As I said above, it is possible but with the following modifications to the instructions on the web site. The packages need to be altered like this:

Code: [Select]
sudo apt-get install libcec-dev libcec4=4.0.1+dfsg1-1+rpi1 libavresample-dev
This installs an old version of libcec. I still need to see if the later version works.

The git clone needs to be at HEAD, not "-b 0.5.0", as there are patches in there to enable compiling on stretch.

Also on my installation I need the following extra line in videoomx.cc

Code: [Select]
@@ -86,6 +86,8 @@ int VideoOMX::init(UCHAR tformat)
   if (initted) return 0;
   initted = 1;

+ bcm_host_init();

I was communicating with Marten Richter about this but I haven't done the fix properly yet. I think he recommended a better place for that line.

After all this, it compiles and works.

3. When I made the last release I tried rolling forward my VDR version as far as possible. I got to 2.2.0 which worked. 2.3.1 broke all four of my VDR plugins and was therefore a step too far. I will have to work on this.

4. Erm, good questions. We should write something on the VDR Wiki.

5. If I remember correctly it was Marten Richter who created the Debian integration. I'm sorry, I hadn't considered those files at all when I made the last release - I've not been near them. This needs work.

6. Yes! What do you want to tackle first? ;)

7. Apparently not! I've always run vomp on single purpose Pis so it running as root hasn't been an issue. I had assumed that all the hardware access would require root permissions but it seems not. There is some code around VT switching that fails when not run as root but it doesn't seem to be making a difference. I will ask Marten what that does.


Having looked at all this in response to your message I think it's definitely time to re-base on Stretch and get a 0.5.1 released, and soon.

Offline Chris

  • Administrator
  • Hero Member
  • *****
  • Posts: 537
    • View Profile
    • Email
Re: vompclient 0.5 features
« Reply #2 on: May 09, 2018, 15:11:24 »
Just out of interest, assuming you use a web VDR manager, which one do you use?

Offline Chris

  • Administrator
  • Hero Member
  • *****
  • Posts: 537
    • View Profile
    • Email
Re: vompclient 0.5 features
« Reply #3 on: May 09, 2018, 16:17:41 »
I've just tested compiling it against the latest libcec library package in Raspbian Stretch and it compiles OK. (I don't know if it actually works...) I think there has been a confusion in the repository with the package names and dependencies which appears to be resolved now if you start with installing libcec4-dev.