Aaargh, forgot to change the vdr Digest from the subject to something reasonable... sorry about the noise... Here's the same with a bit more identifiable subject.
br, Timo
-----------
On Mon, 17 Mar 2008 12:00:02 +0100 Darren Salt linux@youmustbejoking.demon.co.uk wrote:
I demand that Timo Laitinen may or may not have written...
[snip]
Just tackled with this one myself... at least if you used the e-tobi repositories. There was a strange requirement for the library version, I think it was something like libxine => 1.1.12 libxine << 1.1.13.
Highly unlikely.
...
Compilation went well with libxine 1.1.17 and the plugin and the frontends work fine.
1.1.17? Did you get that from... I don't know, probably late next year? :-)
Oops, it seems my time machine had a programming glitch... Or, alternatively, I still haven't learned NOT to trust my memory... So, actually looking at it, it had Build-Depends
libxine-dev (<< 1.1.3), libxine-dev (>= 1.1.2)
, I removed all version requirements, compiled it against libxine 1.1.7. (in Ubuntu Gutsy) But, still, it works, although not perfectly (rapid motion, such as news tickers, are jumpy with xxmc on openchrome when HW acceleration is on, not sure why)
That *is* the general form, though, and it's to do with the name of xine-lib's plugins directory and how the plugin build scripts get the directory name.
So (wrote he hoping), would things get better (regarding my quality problems) if I changed to 1.1.2? or to 1.1.11? Or is it just so that if it works at all, it's ok?
I demand that Timo Laitinen may or may not have written...
Aaargh, forgot to change the vdr Digest from the subject to something reasonable... sorry about the noise... Here's the same with a bit more identifiable subject.
You forgot to correct the In-Reply-To header. ;-)
On Mon, 17 Mar 2008 12:00:02 +0100 Darren Salt linux@youmustbejoking.demon.co.uk wrote:
I demand that Timo Laitinen may or may not have written... [snip]
Just tackled with this one myself... at least if you used the e-tobi repositories. There was a strange requirement for the library version, I think it was something like libxine => 1.1.12 libxine << 1.1.13.
Highly unlikely.
...
Compilation went well with libxine 1.1.17 and the plugin and the frontends work fine.
1.1.17? Did you get that from... I don't know, probably late next year? :-)
Oops, it seems my time machine had a programming glitch... Or, alternatively, I still haven't learned NOT to trust my memory...
I'm inclined to believe the latter: you keep forgetting. :-)
So, actually looking at it, it had Build-Depends libxine-dev (<< 1.1.3), libxine-dev (>= 1.1.2)
The specific versioning shouldn't be there. That sort of thing only belongs in the Depends header, and should be generated at build time.
I removed all version requirements, compiled it against libxine 1.1.7. (in Ubuntu Gutsy) But, still, it works,
:-)
although not perfectly (rapid motion, such as news tickers, are jumpy with xxmc on openchrome when HW acceleration is on, not sure why)
Sounds like an X problem to me, though it could just possibly be to do with xine-lib's xxmc support.
That *is* the general form, though, and it's to do with the name of xine-lib's plugins directory and how the plugin build scripts get the directory name.
So (wrote he hoping), would things get better (regarding my quality problems) if I changed to 1.1.2?
Hopefully not ‒ unless you mean 1.2, in which case you'll see much the same as 1.1 hg wrt xxmc.
or to 1.1.11? Or is it just so that if it works at all, it's ok?
Basically, if you upgrade xine-lib to a newer ABI-compatible version, you won't need to rebuild plugins (except just the once to get them using the new plugin directory naming scheme when you upgrade past 1.1.10.1).
-
Darren Salt -
Timo Laitinen