Hello I use Debian for years and to keep it clean I'm trying to use all software from packages. It generally works, hovewer I have problem with VDR, XBMC and drivers. Usually to have the newest driver I need to use some unstable version of VDR with the newest possible kernel. VDR in Debian is an option, hovewer it's usually behind the newest VDR, and number of plugins in repository is low. This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. Yavdr is built on top of Ubuntu, and while it generally works on Debian, it's not recommended (some things doesn't work). So there is an option to build packages myself - really no option, because I have to make package manually for every plugin and for every new version of VDR. Any idea? Marx
Am 2012-05-08 14:16, schrieb Marx:
Hello I use Debian for years and to keep it clean I'm trying to use all software from packages. It generally works, hovewer I have problem with VDR, XBMC and drivers. Usually to have the newest driver I need to use some unstable version of VDR with the newest possible kernel. VDR in Debian is an option, hovewer it's usually behind the newest VDR, and number of plugins in repository is low. This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. Yavdr is built on top of Ubuntu, and while it generally works on Debian, it's not recommended (some things doesn't work). So there is an option to build packages myself - really no option, because I have to make package manually for every plugin and for every new version of VDR. Any idea?
Any idea to what? Your have not asked any questions. What do you want to know?
Gerald
On 8.5.2012 15:16, Marx wrote:
This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR.
http://qa.debian.org/developer.php?login=etobi@debian.org http://packages.qa.debian.org/v/vdr.html
Tobias Grimm is now in official Debian team.
http://packages.debian.org/search?searchon=names&keywords=vdr
Sid and testing have pretty new versions.
W dniu 2012-05-08 16:10, Pertti Kosunen pisze:
On 8.5.2012 15:16, Marx wrote:
This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR.
http://qa.debian.org/developer.php?login=etobi@debian.org http://packages.qa.debian.org/v/vdr.html
Tobias Grimm is now in official Debian team.
http://packages.debian.org/search?searchon=names&keywords=vdr
Sid and testing have pretty new versions.
I didn't know and that's why his repository isn't updated. In fact I use lately Debian's version (and I was quite suprised that so new version is available in Debian). Hovewer number of available plugins in Debian is pretty low. Do you know if he plans to migrate more of them to Debian? Marx
On 08.05.2012 18:34, Marx wrote
I didn't know and that's why his repository isn't updated. In fact I use lately Debian's version (and I was quite suprised that so new version is available in Debian). Hovewer number of available plugins in Debian is pretty low. Do you know if he plans to migrate more of them to Debian?
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
And my e-tobi.net-repository has been updated this morning. But there are some old plugins with no upstream activity that I haven't migrated to VDR 1.7.27 yet. I will do this on request (just drop me a mail) and will drop the remaining plugins if nobody misses them.
Tobias
On Tue, May 8, 2012 at 11:29 AM, Tobi listaccount@e-tobi.net wrote:
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
If you haven't added it already, you should consider adding softhddevice. People have wanted an alternative to the xinelib-based options (vdr-xine, xineliboutput) and this newish plugin offers just that. It currently supports vdpau, with more coming (although most users seem to only use vdpau or software decoding anyways). It also supports toggling between stereo mixdown and surround sound without restarting anything which I love as a feature.
On Tue, 08 May 2012 20:29:13 +0200 Tobi listaccount@e-tobi.net wrote:
On 08.05.2012 18:34, Marx wrote
I didn't know and that's why his repository isn't updated. In fact I use lately Debian's version (and I was quite suprised that so new version is available in Debian). Hovewer number of available plugins in Debian is pretty low. Do you know if he plans to migrate more of them to Debian?
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids.
On 09/05/12 00:54, Tony Houghton wrote:
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids.
I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it.
Tbh, it would probably be better if someone coded it from scratch.
On Wed, 09 May 2012 12:14:48 +0100 Dominic Evans oldmanuk@gmail.com wrote:
On 09/05/12 00:54, Tony Houghton wrote:
I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids.
I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it.
Tbh, it would probably be better if someone coded it from scratch.
Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports.
On 09/05/12 14:32, Tony Houghton wrote:
On Wed, 09 May 2012 12:14:48 +0100 Dominic Evansoldmanuk@gmail.com wrote:
On 09/05/12 00:54, Tony Houghton wrote:
I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids.
I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it.
Tbh, it would probably be better if someone coded it from scratch.
Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports.
A smaller amount of work might be just to extend the patch to add a setup option to VDR's menus to enable/disable it (and have it disabled by default).
The it could potentially be added to the standard patchlist for debian/ubuntu/yavdr.
On Wed, 09 May 2012 16:31:23 +0100 Dominic Evans oldmanuk@gmail.com wrote:
On 09/05/12 14:32, Tony Houghton wrote:
On Wed, 09 May 2012 12:14:48 +0100 Dominic Evansoldmanuk@gmail.com wrote:
[Problems with eepg]
Tbh, it would probably be better if someone coded it from scratch.
Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports.
A smaller amount of work might be just to extend the patch to add a setup option to VDR's menus to enable/disable it (and have it disabled by default).
The it could potentially be added to the standard patchlist for debian/ubuntu/yavdr.
That sounds like a good idea. Tobias, would you be willing to add this patch if enabling it is made optional?
On Wed, 09 May 2012 21:49:04 +0200 Tobi listaccount@e-tobi.net wrote:
On 09.05.2012 18:16, Tony Houghton wrote:
That sounds like a good idea. Tobias, would you be willing to add this patch if enabling it is made optional?
Not if this can be done with a plugin as well.
Where can I find the most recent version of the patch?
This is the latest version which Mario Schulz sent me. It has the Huffman tables built in to the code now instead of as separate files.
On Wed, May 9, 2012 at 4:14 AM, Dominic Evans oldmanuk@gmail.com wrote:
I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it.
Do you have any details about these memory leaks? Also, do they exist in the current git of eepg or is your local copy older? If current eepg git contains memory leaks then please share what you've found so that they may be fixed.
I'm using a new testing version of eepg at the moment and have started to monitor memory usage, but have not seen anything bad.
Thanks
On 8.5.2012 21:29, Tobi wrote:
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
http://projects.vdr-developer.org/projects/plg-ttxtsubs
Ttxtsubs would be nice.
Hello Tobias,
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
And my e-tobi.net-repository has been updated this morning. But there are some old plugins with no upstream activity that I haven't migrated to VDR 1.7.27 yet. I will do this on request
I would need the vdr-plugin-imonlcdhttp://www.vdr-wiki.de/wiki/index.php/Imonlcd-plugin for my IMON LCD in the Antec Fusion case. It would be grate if you would migrate this plugin to 1.7.27. One of the reasons why I bought this case was the LCD. Please let me know what you decide to do with this plugin.
Another plugin which I miss is the vdr-plugin-burn.
Thanks, Winfried
Hi,
I just noticed, that the missing plugins for squeeze are already in Tobi's VDR repository. Sorry for the confusion!
But I can't upgrade:
The following packages have unmet dependencies: vdr-plugin-chanorg: Depends: vdr-abi-1.7.23-multipatch which is a virtual package. vdr-plugin-burn: Depends: vdr-abi-1.7.23-multipatch which is a virtual package. vdr-plugin-imonlcd: Depends: vdr-abi-1.7.23-multipatch which is a virtual package.
Any ideas?
Am 12.05.2012 11:50, schrieb abang:
Hello Tobias,
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
And my e-tobi.net-repository has been updated this morning. But there are some old plugins with no upstream activity that I haven't migrated to VDR 1.7.27 yet. I will do this on request
I would need the vdr-plugin-imonlcd for my IMON LCD in the Antec Fusion case. It would be grate if you would migrate this plugin to 1.7.27. One of the reasons why I bought this case was the LCD. Please let me know what you decide to do with this plugin.
Another plugin which I miss is the vdr-plugin-burn.
Thanks, Winfried
On Sat, May 12, 2012 at 7:47 AM, abang abang@t-ipnet.net wrote:
I just noticed, that the missing plugins for squeeze are already in Tobi's VDR repository. Sorry for the confusion!
But I can't upgrade:
The following packages have unmet dependencies: vdr-plugin-chanorg: Depends: vdr-abi-1.7.23-multipatch which is a virtual package. vdr-plugin-burn: Depends: vdr-abi-1.7.23-multipatch which is a virtual package. vdr-plugin-imonlcd: Depends: vdr-abi-1.7.23-multipatch which is a virtual package.
Any ideas?
Do all those plugins _actually_ depend on that patch? I can't imagine they do. Just remove the dependency. If they work, the debian/control file needs to be fixed so the needless dependency is removed.
Am 12.05.2012 17:32, schrieb VDR User:
On Sat, May 12, 2012 at 7:47 AM, abangabang@t-ipnet.net wrote:
I just noticed, that the missing plugins for squeeze are already in Tobi's VDR repository. Sorry for the confusion!
But I can't upgrade:
The following packages have unmet dependencies: vdr-plugin-chanorg: Depends: vdr-abi-1.7.23-multipatch which is a virtual package. vdr-plugin-burn: Depends: vdr-abi-1.7.23-multipatch which is a virtual package. vdr-plugin-imonlcd: Depends: vdr-abi-1.7.23-multipatch which is a virtual package.
Any ideas?
Do all those plugins _actually_ depend on that patch? I can't imagine they do. Just remove the dependency. If they work, the debian/control file needs to be fixed so the needless dependency is removed.
Ist is not a patch. It is the name of the ABI version. Debian packages are using this ABI version to prevent that vdr and vdr plugins with different ABIs get mixed up.
The error message means, the mentioned plugins do not belong to the vdr that abang is using.
Gerald
On 8 May 2012 19:29, Tobi listaccount@e-tobi.net wrote:
On 08.05.2012 18:34, Marx wrote
I didn't know and that's why his repository isn't updated. In fact I use lately Debian's version (and I was quite suprised that so new version is available in Debian). Hovewer number of available plugins in Debian is pretty low. Do you know if he plans to migrate more of them to Debian?
Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon.
I noticed that http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-markad.git is actively maintained, but no deb has been uploaded to debian archive. Do you plan to upload one whenever vdr 1.7.41 / vdr 2.0.0 gets uploaded to unstable/experimental ?
On 18.03.2013 15:43, Dominic Evans wrote:
I noticed that http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-markad.git is actively maintained, but no deb has been uploaded to debian archive. Do you plan to upload one whenever vdr 1.7.41 / vdr 2.0.0 gets uploaded to unstable/experimental ?
Yes. Markad will be added and weather and vcd will most likely be dropped.
Tobias
On 18.03.2013 20:11, Tobi wrote:
On 18.03.2013 15:43, Dominic Evans wrote:
I noticed that http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-markad.git is actively maintained, but no deb has been uploaded to debian archive. Do you plan to upload one whenever vdr 1.7.41 / vdr 2.0.0 gets uploaded to unstable/experimental ?
Yes. Markad will be added and weather and vcd will most likely be dropped.
what about softhddevice? As i saw vdr running script in Debian doesn't play well with softhddevice (restart vdr while softhddevice is initializing) Marx
On 19.03.2013 08:51, Marx wrote:
what about softhddevice? As i saw vdr running script in Debian doesn't play well with softhddevice (restart vdr while softhddevice is initializing) Marx
I've already packaged softhddevice, but I need to test it before I decide to upload it to Debian.
http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-softhddevice.git;...
Tobias
On 19.03.2013 10:44, Tobi wrote:
On 19.03.2013 08:51, Marx wrote:
what about softhddevice? As i saw vdr running script in Debian doesn't play well with softhddevice (restart vdr while softhddevice is initializing) Marx
I've already packaged softhddevice, but I need to test it before I decide to upload it to Debian.
http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-softhddevice.git;...
what about: - vdr-plugin-vnsiserver - seems outdated: 0.0.1~svn20100428+frodo-1. would be nice to have version corresponding with stable frodo VNSI plugin
-noepg - plugin is simple so easy to package and it would be nice to have it in repo. I use it, maybe others too?
Marx
On 19.03.2013 15:13, Marx wrote:
what about:
- vdr-plugin-vnsiserver - seems outdated: 0.0.1~svn20100428+frodo-1. would
be nice to have version corresponding with stable frodo VNSI plugin
Can you point me to the upstream sources? Is there an official version of the VNSI plugin for Frodo?
-noepg - plugin is simple so easy to package and it would be nice to have it in repo. I use it, maybe others too?
Just updated it to the latest version:
http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-noepg.git;a=summa...
Tobias
On 20.03.2013 00:01, Tobi wrote:
Can you point me to the upstream sources? Is there an official version of the VNSI plugin for Frodo?
Based on http://forum.xbmc.org/showthread.php?tid=139675 here it is: https://github.com/opdenkamp/xbmc-pvr-addons/tree/master/addons/pvr.vdr.vnsi There is somewhere repo of developer, FernetMenta, but I think those source should perfectly fit XBMC plugin
-noepg - plugin is simple so easy to package and it would be nice to have it in repo. I use it, maybe others too?
Just updated it to the latest version:
http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-noepg.git;a=summa...
Thank you :)
Marx
On Wednesday, 20 March 2013, Marx wrote:
On 20.03.2013 00:01, Tobi wrote:
Can you point me to the upstream sources? Is there an official version of the VNSI plugin for Frodo?
Based on http://forum.xbmc.org/**showthread.php?tid=139675http://forum.xbmc.org/showthread.php?tid=139675 here it is: https://github.com/opdenkamp/**xbmc-pvr-addons/tree/master/** addons/pvr.vdr.vnsihttps://github.com/opdenkamp/xbmc-pvr-addons/tree/master/addons/pvr.vdr.vnsi There is somewhere repo of developer, FernetMenta, but I think those source should perfectly fit XBMC plugin
Here is correct link for stable frodo version, VDR plugin subdir
https://github.com/opdenkamp/xbmc-pvr-addons/tree/frodo/addons/pvr.vdr.vnsi/...
there is already a Debian packaging branch too with Debian/ structure.
https://github.com/opdenkamp/xbmc-pvr-addons/tree/packaging/debian
There is somewhere repo of developer, FernetMenta, but I think those source should perfectly fit XBMC plugin
I've updated the plugin:
http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-vnsiserver.git;a=...
But I this is still considered unstable, so right now this is no candidate to be uploaded to Debian.
Tobias
On Tue, May 8, 2012 at 5:16 AM, Marx acc.for.news@gmail.com wrote:
Hello I use Debian for years and to keep it clean I'm trying to use all software from packages. It generally works, hovewer I have problem with VDR, XBMC and drivers. Usually to have the newest driver I need to use some unstable version of VDR with the newest possible kernel. VDR in Debian is an option, hovewer it's usually behind the newest VDR, and number of plugins in repository is low. This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. Yavdr is built on top of Ubuntu, and while it generally works on Debian, it's not recommended (some things doesn't work). So there is an option to build packages myself - really no option, because I have to make package manually for every plugin and for every new version of VDR. Any idea?
Why don't you just write a script that automates it all for you. If it encounters an error along the way, just abort and report the error to the user. Building VDR and plugins from source is very easy assuming you don't bother with tons of patches (which can break things quickly).
It's also very easy to add in support for updating the kernel, media_build drivers, nvidia drivers, etc.. This is exactly what I did and I almost never have to actually do anything by hand anymore -- just select what I want from my menu and it magically happens. ;)
I'm not as good in writing scripts as you :) Do you install VDR from sources, or build debian packages? I know it's not so hard to build everything manually and in fact I did it many times. Hovewer packages in yavdr or e-tobi repositories were easier to install, and it was sure they will work together. Sometimes VDR or packages are patched to work better by maintainer of repo. I don't need to follow all git svn of all plugins and cope with some problems of compiling it myself, if somebody did it. I think it's better to use his work because it's better in it and additionally i test his work. Sometimes I'm in hurry to test some "super new plugin". Aptitude, search, install, restart vdr and test - it gets a few minutes and afterall it's easy to unistall it too. And while new version of VDR is published, i simple aptitude, update and go - I have new version with all new plugins. That's why I like having VDR in packages. Knowing that Debian has "master od VDR" ;) in his team is very good info and I will try to stick with this version Marx
On Tue, May 8, 2012 at 9:45 AM, Marx acc.for.news@gmail.com wrote:
I'm not as good in writing scripts as you :) Do you install VDR from sources, or build debian packages?
Scripting is really easy once you know it. If not, no worries, it's easy to learn too. :)
When I first started with VDR, I installed it. Then I switched to building debian packages at one point. Later I realized it was useless for me to bother installing/using packages and I just compile & run it from it's source dir. I have a /vdr symlink which I always point to whichever source dir I want to use to `cd /vdr` always gets me to the current source dir, or `/vdr/vdr` always runs my current VDR. For me it just didn't make sense to have plugins here, VDR binary there, settings over there, other data over here.. But the great part is everyone can configure it however they like!
I know it's not so hard to build everything manually and in fact I did it many times. Hovewer packages in yavdr or e-tobi repositories were easier to install, and it was sure they will work together. Sometimes VDR or packages are patched to work better by maintainer of repo. I don't need to follow all git svn of all plugins and cope with some problems of compiling it myself, if somebody did it. I think it's better to use his work because it's better in it and additionally i test his work. Sometimes I'm in hurry to test some "super new plugin". Aptitude, search, install, restart vdr and test - it gets a few minutes and afterall it's easy to unistall it too. And while new version of VDR is published, i simple aptitude, update and go - I have new version with all new plugins. That's why I like having VDR in packages. Knowing that Debian has "master od VDR" ;) in his team is very good info and I will try to stick with this version
Those repositories are definitely a good choice for some people. At the end of the day, people seem to prefer `plug & play` solutions. I don't bother with them mostly because they have a ton of junk I don't need/want patched in, and they don't support all the NA needs as far as I know (maybe it has changed now). I also like to test VDR & plugins so _for me_ working with source is the best in case I need to edit something for testing purposes.
I give the same advice for VDR as I do with any software in general -- just pick what works best for your needs/wants. There's some software I'd much rather apt-get than compile myself. :)
-
abang -
Dominic Evans -
Gerald Dachs -
Marx -
Pertti Kosunen -
Tobi -
Tony Houghton -
VDR User