Re: 13.1M4/KDE4.11&12.3/KDE4.10.5: system sounds, SMplayer2 OK; no VLC sound
David Haller <[email protected]> Mon, 16 Sep 2013 12:07:21 +0200
| Newsgroups | gmane.linux.suse.multimedia |
|---|---|
| Organization | What? |
| Message-ID | <[email protected]> |
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: [email protected]
To contact the owner, e-mail: [email protected]