Hello, On Sat, 14 Sep 2013, Felix Miata wrote:
On 2013-09-14 22:07 (GMT+0200) David Haller composed:
On Sat, 14 Sep 2013, Felix Miata wrote:
On 2013-09-13 20:28 (GMT+0200) David Haller composed:
On Fri, 13 Sep 2013, Felix Miata wrote:
These are installed 12.3 packages.
vlc-codecs-2.0.8a-150.2.x86_64
Do you have libmpeg2 installed? It's needed by /usr/lib64/vlc/plugins/codec/liblibmpeg2_plugin.so
Yes, if libmpeg2-0-0.5.1-7.1.x86_64 in 12.3 counts.
That should be fine. I've got libmpeg2-0-0.5.1-1.5.x86_64 on 12.1. Haven't checked what's changed in PMBS between rel. 1 and 7.
And I haven't noticed anything not playing with anything (vlc, mplayer, xine)
Does that package verify fine? Does
$ rpm -Vf /usr/lib64/libmpeg2.so.0
output anything? If not, that package is fine and I've run out of
null output
Good.
ideas. Hm. Maybe re-check available updates ... Sadly Packman does only keep the most recent version in the Repos...
It seems Packman has updates daily.
Well, that depends. Some packages do trigger quite a lot of rebuilds though (e.g. ffmpeg on which a lot of packages depend). [..]
# zypper -v up
The following package updates will NOT be installed: [..]
You may want to check on those (e.g. with yast2) if they're still needed ...
The following packages are going to be upgraded: [..] 69 packages to upgrade, 3 new.
Probably vlc / libmpeg got out of sync, i.e. one was rebuilt and mirrored while the other was still on the way to your mirror.
Overall download size: 128.9 MiB. After the operation, 4.4 MiB will be freed. Continue? [y/n/?] (y):
Maybe what's happening here is a result of a mixture of Packman and standard repo packages that a mere zypper up won't resolve? What to do? Should I just say yes yet again?
Yes. Basically. Generally I think it'd be good if you'd fire up 'yast2 online_update', switch to the "Repository" view, choose packman repo and then click on the "switch ... to this repository" link above the package list. You should check the changes though, there may be some packages you'd rather have from some other repo (e.g. some game may be newer in the games repo, that depends on your repos). You can switch those packages back to that other repo via the "Version" tab. A bit tedious, but once done and with right priorities of the repos, it works quite nicely. Oh, but if you could do the stuff below (at least the ldd and the test with cvlc) first, before you run the update, it'd help us all to better diagnose similar problems in the future. E.g. if the suspected "out of sync" can be diagnosed via the ldd/cvlc outputs ... If you do the update first, we won't know ...
If you've then tried that, one could try ltracing [c]vlc to better see where it fails (e.g. 'ltrace -S 128 -f -o foo.ltrace cvlc for the ML, PM is ok).
I'm not clear what it is you're suggesting here. What are [c]vlc, ltrace and foo.ltrace?
It's a (faulty) command line, but I think it's not the next step yet anyway. The command line: ltrace -S -s 128 -f -o foo.ltrace cvlc -v --play-and-exit foo.mpeg is: ltrace (see man ltrace, you might need to install it first, it's a "library call trace" similar to "strace" which traces system calls) -S have ltrace also display system calls -s 128 output strings 128 chars long (default is quite short, often too short) -f follow forks (calls of other processes) -o foo.ltrace have ltrace write its output to the file foo.ltrace in the current directory cvlc have ltrace start the binary(!)[1], cvlc is the commandline/guiless vlc. [... the rest ...] options and argument for the binary (here: 'cvlc'). --play-and-exit is an option for cvlc to play the file and then exit which [c]vlc won't do otherwise [1] if it's a script (bash, perl etc.) you have to call it via the interpreter e.g. 'ltrace /bin/bash -- foo.sh --foo-opt foo-arg' or 'ltrace perl -- foo.pl'. So, I hope I could explain that, but as mentioned, that's not the next best step anyway (I've thought some more about it). ltrace is a very powerful tool for debugging (even more than strace) but not easy to use (esp. reading the output ;) But it's something I preinstall in my "OBS" prefs (oh, that reminds me: have to put that in my PMBS prefs too) for when I build/debug stuff locally prior to committing to the OBS ;) So I can use "[sl]trace" in a .spec file while building stuff with OBS. Very useful. Solved quite a few nasties that way. Anyway: You should first do a ldd /usr/lib64/vlc/plugins/codec/liblibmpeg2_plugin.so and mail the output here. Then you should call cvlc -v --play-and-exit foo.mpeg (with any file "foo.mpeg" you can't play) and mail that output (or put it on paste.opensuse.org). If somethings amiss with the libs, there should be some error about a missing symbol or some such in the output of cvlc. E.g. I get: [0x607558] main libvlc warning: cannot load module `/usr/lib64/vlc/plugins/services_discovery/libupnp_plugin.so' (libupnp.so.6: cannot open shared object file: No such file or directory) for any file I play. I "broke" the dependency on libupnp because I don't want that on my box and I don't want the libupnp_plugin to work, so that's just as I intended :) In your case, it could be something like [..] cannot load module: `/usr/lib64/vlc/plugins/codec/liblibmpeg2_plugin.so' (missing symbol ...) or something along that line, which would disable playing mpeg2 and which is not "as intended"...
There's also libmpeg123-0.
Are you *sure* it's not libmpg123? That belongs to mpg123, which is an audioplayer:
# rpm -qa | grep libmp libmpg123-0-1.15.4-1.4.x86_64
*heh*
libmpg123* != libmpeg* ;)
HTH, -dnh -- Picard: "Worf, fire at will!" Worf: "Aye, sir!" Riker: "*AAARGH*" -- Timm Thiemann in de.alt.sysadmin.recovery -- To unsubscribe, e-mail: opensuse-multimedia+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-multimedia+owner@opensuse.org