Bug#881489: playback scaled to 4k fullscreen is choppy
On 12/11/17 18:23, Sebastian Ramacher wrote: > On 2017-11-12 18:06:51, Daniel Pocock wrote: >> >> Should the automatic setting use a different default? > > Depends(TM), I guess. > Reported upstream https://trac.videolan.org/vlc/ticket/19077 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#881489: playback scaled to 4k fullscreen is choppy
On 12/11/17 17:43, Sebastian Ramacher wrote:
> Control: tags -1 + moreinfo
>
> On 2017-11-12 11:23:24, Daniel Pocock wrote:
>> Package: vlc
>> Version: 2.2.6-1~deb9u1
>>
>>
>> Trying to play a video file with a resolution 720x526, 25fps, MPEG-1/2
>> (problem also observed with other videos at different resolutions)
>>
>> With the window maximized and the option "Always Fit Window" selected,
>> it appears to zoom to 3:1 and playback appears good.
>>
>> When fullscreen is selected (up to the 4k resolution of the display), I
>> frequently see what appears to be a horizontal tear across the middle of
>> the picture, especially when there is a lot of movement in the video.
>>
>> Using mpv 0.23.0-2+b2 at fullscreen with the same video I don't observe
>> the problem.
>>
>> I don't have libvdpau1 installed due to problems with the frame rate[1]
>>
>> Hardware is Intel i3-7100U CPU @ 2.40GHz and Kaby Lake integrated
>> graphics Intel HD Graphics 620 (Kabylake GT2)
>
> Please provide the output of vlc -vvv. Did you try selecting different video
> output modules (e.g. the OpenGL one)?
>
I had a look at the preferences window, video tab. The "Output" option
was automatic.
Looking at the logs, I notice it was selecting xcb_xv (XVideo)
[7f3a54001268] xcb vout display debug: connected to X11.0 server
[7f3a54001268] xcb vout display debug: vendor : The X.Org Foundation
[7f3a54001268] xcb vout display debug: version: 11902000
[7f3a54001268] xcb vout display debug: using screen 0xf5
[7f3a54001268] xcb_xv vout display debug: using XVideo extension v2.2
[7f3a54001268] xcb_xv vout display debug: using adaptor Intel(R)
Textured Video
[7f3a54001268] xcb_xv vout display debug: using port 74
[7f3a54001268] xcb_xv vout display debug: using image format 0x30323449
[7f3a54001268] xcb_xv vout display debug: using X11 visual ID 0x20
(depth: 24)
[7f3a54001268] xcb_xv vout display debug: using X11 window 0x0320
[7f3a54001268] xcb_xv vout display debug: using X11 graphic context
0x0322
[7f3a54001268] core vout display debug: VoutDisplayEvent 'fullscreen' 0
[7f3a54001268] core vout display debug: VoutDisplayEvent 'resize'
3840x2017 window
[7f3a54001268] core vout display debug: using vout display module
"xcb_xv"
I manually changed it to "OpenGL GLX video output (XCB)" and the problem
goes away.
[7f10c8001268] core vout display debug: using vout display module
"xcb_glx"
Looking at the mpv logs as well, it appears to be using OpenGL by default:
[vo/opengl] Initializing OpenGL backend 'wayland'
[vo/opengl/wayland] failed to connect to a wayland server: check if a
wayland compositor is running
[vo/opengl] Initializing OpenGL backend 'x11probe'
[vo/opengl/x11] X11 opening display: :1
[vo/opengl/x11] X11 running at 3840x2160 (":1" => local display)
[vo/opengl/x11] Detected wm supports NetWM.
[vo/opengl/x11] Detected wm supports FULLSCREEN state.
[vo/opengl/x11] Detected wm supports ABOVE state.
[vo/opengl/x11] Detected wm supports BELOW state.
[vo/opengl/x11] Display 0 (DP1): [0, 0, 3840, 2160] @ 30.00 FPS
...
[vf] Video filter chain:
[vf] [in] 720x576 [64:45] yuv420p bt.601/bt.601-625/bt.1886/limited
CL=mpeg2/4/h264
[vf] [out] 720x576 [64:45] yuv420p bt.601/bt.601-625/bt.1886/limited
CL=mpeg2/4/h264
[cplayer] VO: [opengl] 720x576 => 1024x576 yuv420p
[cplayer] VO: Description: Extended OpenGL Renderer
Is there any other detail I should look for in the log?
Should the automatic setting use a different default?
Regards,
Daniel
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#881489: playback scaled to 4k fullscreen is choppy
Package: vlc Version: 2.2.6-1~deb9u1 Trying to play a video file with a resolution 720x526, 25fps, MPEG-1/2 (problem also observed with other videos at different resolutions) With the window maximized and the option "Always Fit Window" selected, it appears to zoom to 3:1 and playback appears good. When fullscreen is selected (up to the 4k resolution of the display), I frequently see what appears to be a horizontal tear across the middle of the picture, especially when there is a lot of movement in the video. Using mpv 0.23.0-2+b2 at fullscreen with the same video I don't observe the problem. I don't have libvdpau1 installed due to problems with the frame rate[1] Hardware is Intel i3-7100U CPU @ 2.40GHz and Kaby Lake integrated graphics Intel HD Graphics 620 (Kabylake GT2) Regards, Daniel 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856535 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#873843: fails with error "found multiple ISRC commands"
Package: flac
Version: 1.3.2-1
$ flac ... --cuesheet=disc.cue data.bin
fails with this error:
data.bin: ERROR parsing cuesheet "disc.cue" on line 17:
found multiple ISRC commands
The CUESHEET was obtained by this series of commands:
cdrdao read-cd --device $CDDEV --driver generic-mmc-raw \
--read-raw ${TOC_FILE}
cueconvert $TOC_FILE} disc.cue
The TOC contains two ISRC entries for each track:
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC "GBCLS1234567"
CD_TEXT {
LANGUAGE 0 {
TITLE "foo"
PERFORMER "foo"
SONGWRITER ""
COMPOSER "foo"
ARRANGER "foo"
DISC_ID ""
ISRC "GB-CLS-12-34567"
}
}
FILE "data.bin" 0 03:21:23
and the CUESHEET contains entries like this for each track:
ISRC "GB-CLS-12-34567"
ISRC GBCLS1234567
May be related to bug #815587
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#815587: flac fails with "invalid ISRC number" when multiple ISRC attributes exist for a track
Package: flac
Version: 1.3.0-3
I've gone through a collection of discs and 2 of them fail with errors
like this:
data.bin: ERROR parsing cuesheet "/mnt/cdrip/incoming/foo_bar/disc.cue"
on line 11: invalid ISRC number
The discs were originally processed with cdrdao which produces a TOC
file containing something like this:
// Track 1
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC "USSM12345678"
CD_TEXT {
LANGUAGE 0 {
TITLE "Foo"
PERFORMER "Bar"
DISC_ID ""
ISRC "US-SM1-23-45678"
}
}
FILE "data.bin" 0 01:23:45
and then I put that through cueconvert:
cueconvert disc.toc disc.cue
which puts the following in the disc.cue:
FILE "data.bin" WAVE
TRACK 01 AUDIO
TITLE "Foo"
PERFORMER "Bar"
DISC_ID ""
ISRC "US-SM1-23-45678"
ISRC USSM12345678
INDEX 01 00:00:00
and then I run flac:
flac --best \
--force-raw --sample-rate=44100 --channels=2 --bps=16 \
--endian=big --sign=signed \
--cuesheet=disc.cue data.bin -o disc.flac
The line referred to in the error is the line with a quoted ISRC string.
Should the flac command tolerate these cuesheet files? Should this bug
be assigned to cueconvert or cdrdao?
There is a similar bug here:
https://sourceforge.net/p/flac/bugs/436/
but it only refers to quoted ISRC values, not the case of multiple ISRC
values per-track.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#701044: Processed: severity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/02/16 10:52, Sebastian Ramacher wrote: > Control: severity -1 normal > > On 2016-02-16 09:48:09, Debian Bug Tracking System wrote: >> Processing commands for cont...@bugs.debian.org: >> >>> severity 701044 serious >> Bug #701044 [src:libmusicbrainz5] flactag errors when run >> Severity set to 'serious' from 'normal' > > When you raise a severity to serious, you have to give a > justification. Also, That was sent in a separate email > there is easy workaround for this bug. Just pipe stderr to > /dev/null. > I tried redirecting stderr to a file and flactag wouldn't run at all, the stderr file just contained some HTTP error code I tried again just now and I notice flactag's Rename operation calls the file NOARTIST-NOALBUM.flac so it looks like this bug / API change makes it almost completely nonfunctional. > Setting the severity back to normal. Personally, I think the issues with REST APIs like this changing around need to be on the radar of the release team well before the freeze, hence severity serious or higher. Maybe the MusicBrainz people can provide a legacy API. Maybe Debian can reduce our dependency on packages with these issues or look at ways to make it easier to update such packages during the life of a stable release. There are a whole class of packages with issues like this now due to dependencies on public REST services yet I haven't seen any Debian strategy for dealing with it. For more exotic packages the updates can just be made available through backports but this is a package installed by default on most desktops. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWwvc9AAoJEGxlgOd711bEDgAQAKMNNmQYrfnKIlABrWm1G91y v3bL3KpW665bKnp/32g/fsT2FK5q7IDguSlwHxfDGKoY13Sb7NRDcJy9UridnKxM AruFvJNbGZGp5JKpjbWT8O0hAHxRxDAkCP93ZuSxtEKsl0DCpb4z/GuklW6HW/It BPnVg1+V516KKQVu3aO5q7qDfLA2zpcLdmJWIk+10KTw0Ps5E4Rmvd1PbPShGr94 2pwANeik75y9sG5WHDW7dRiPpsR+x/LEkNIsmAyGqFsEaZMwOYBSiwPVOr03a0Ym YYLIxSyZy7PqrLQqu3TzpXFW4iMhXPFQuBfH2bRVh5+pISAT+NQXdoU8G7bpk4X/ ypEqraKCsthWV8pj+tX68TPHelq5k+fyycleIHo3FuJTpiVydchdezdnGPWlPXZK a/3jsxtlFYIjfBjVBfyupxlqENRUBw4EA3Nf4YMc+uQl1XlXfMavN9YBvj4NOZnn jPNNtmRv3ug0tdHkplWPOAYvsZljKX7IcyTHTSis7nFXDOEmmNTvTjmvF7V6HUoA 04M0+DtNYd9+/RlohQ+/r2+qzmOND2Itao5Fc5cpjm0fLdHO1j3mA0q6S36Hh5zb kNU/y6wLc3OgLSHJjUCHalFSRxN2Dx1hWflEMX+u7yWkuKdDTvuiUOVazW30mvjg mn6XR6sQYCNV+Q0tZ8Ml =d1UP -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#701044: updating severity, workarounds
I've updated the severity of this bug to serious because a) it corrupts the display in other applications using this library (e.g. flactag) b) it is not clear what impact it has on other applications if some elements and attributes are not processed (flactag doesn't appear to complete writing the tags to a FLAC file) Even if fixing the bug/adding full support for these other elements/attributes is not immediately possible, the severity of this bug could probably be downgraded with some combination of the following solutions: - allow the applications to direct the log messages elsewhere (e.g. a file or a window) - MusicBrainz provides a legacy REST/HTTP API that works with this version of the library for as long as the stable version of Debian is supported (approximately 3 years from release) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#814813: spurious output to stderr
Package: flactag Severity: important When starting up and also after pressing the 'W' key to write, flactag is sending a whole lot of errors to stderr. From comments in the discussion forums it looks like they may be originating from libmusicbrainz When the errors appear after displaying the UI, they corrupt the UI, it is no longer possible to see the list of keystrokes at the bottom of the screen. Pressing 'Q' exits the application though. - what is the impact of ignoring these elements? Should flactag just ignore them (or have a command line switch to ignore them) without printing errors? - could the errors be shown in the UI? Maybe libmusicbrainz needs to support some logging framework and the UI could then intercept log messages to display them cleanly Unrecognised disc element: 'offset-list' Unrecognised release element: 'release-event-list' Unrecognised release element: 'cover-art-archive' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised release element: 'release-event-list' Unrecognised release element: 'cover-art-archive' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised release element: 'release-event-list' Unrecognised release element: 'cover-art-archive' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised release element: 'release-event-list' Unrecognised release element: 'cover-art-archive' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised relation attribute: 'type-id' Unrecognised relation attribute: 'type-id' Unrecognised release element: 'release-event-list' Unrecognised release element: 'cover-art-archive' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised disc element: 'offset-list' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised relation attribute: 'type-id' Unrecognised relation attribute: 'type-id' Unrecognised release element: 'release-event-list' Unrecognised release element: 'cover-art-archive' Unrecognised disc element: 'offset-list' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised disc element: 'offset-list' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised disc element: 'offset-list' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id' Unrecognised track attribute: 'id'
Bug#800802: progress
Issue (c), warnings about cuesheets from mkcue, may have been caused by another bug in the checkflac script. The line FLACID=`flactag --discid $FILENAME | cut -d':' -f 2| cut -d' ' -f 2` sets an empty $FLACID if the $FILENAME contains a space. It should be wrapped in double quotes. I've fixed it in upstream commit 346d0ad569d7f6bf0a8232975712a42991a5650c After fixing the checkflac script, I ran it against the same CD and the disc IDs match. I've also addressed issue (a) in the same commit, the checkflac output now puts the word INVALID next to the disc ID from the FLAC file so it is clear which disc ID should be removed from MusicBrainz. While the disc ID is valid, the mkcue cuesheets don't contain pre-gap. It doesn't appear to need pre-gap for calculating disc ID, but some people may want their collection to be perfect, so they can reconstruct the original CD from the FLAC. Maybe the checkflac script should also do a check to see if pre-gap information is missing and display a different error for that? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#800802: checkflac usage
Package: flactag Version: 2.0.4-3+b1 X-Debbugs-CC: a...@gently.org.uk,mo...@debian.org The flactag manpage[1] gives a brief overview of the cueconvert problem[2] (also forwarded upstream[3]) but it is not completely clear: a) the output of checkflac tells the user to remove any invalid disc IDs from the MusicBrainz service. Which of the disc IDs is invalid though? Maybe it should display the invalid disc ID in the message. b) the man page says that the CDs need to be ripped again. Is it really necessary to rip the whole disc again, or is it possible to just extract the TOC again, create a proper cuesheet and embed that into the FLAC file, replacing the bad one? c) I had used mkcue[4] to get CUE sheets when processing some CDs. I tested one with checkflac and it says it is bad. mkcue doesn't appear to use cuetools, is it also known to be buggy or should I check it more thoroughly? 1. https://anonscm.debian.org/cgit/pkg-multimedia/flactag.git/tree/flactag.1.txt 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399517 3. https://github.com/svend/cuetools/issues/5 4. https://packages.qa.debian.org/m/mkcue.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#758543: same problem
I just did a dist-ugprade from wheezy to jessie last week and I have this same error message. $ mplayer *.flac mplayer: error while loading shared libraries: libdvdnavmini.so.4: cannot open shared object file: No such file or directory Here is what I have on my system after running apt-get dist-upgrade: $ dpkg -l | egrep 'libdvdnav|mplayer' ii libdvdnav4:amd645.0.1-1 amd64DVD navigation library ii mplayer 3:1.1-dmo9 amd64Ultimate Movie Player For Linux. packages.debian.org tells me mplayer is now a virtual package provided by the mplayer2 package. https://packages.debian.org/jessie/mplayer It seems that what I should have is the mplayer2 package but it wasn't installed during my dist-upgrade I was able to manually get it changed to the mplayer2 package and now it works: # apt-get install mplayer2 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: mplayer The following NEW packages will be installed: mplayer2 0 upgraded, 1 newly installed, 1 to remove and 71 not upgraded. Need to get 952 kB of archives. After this operation, 12.7 MB disk space will be freed. Do you want to continue? [Y/n] y Get:1 http://mirror.switch.ch/ftp/mirror/debian/ jessie/main mplayer2 amd64 2.0-728-g2c378c7-4+b1 [952 kB] Fetched 952 kB in 0s (1,720 kB/s) (Reading database ... 406889 files and directories currently installed.) Removing mplayer (3:1.1-dmo9) ... Processing triggers for mime-support (3.58) ... Processing triggers for man-db (2.7.0.2-5) ... Selecting previously unselected package mplayer2. (Reading database ... 406871 files and directories currently installed.) Preparing to unpack .../mplayer2_2.0-728-g2c378c7-4+b1_amd64.deb ... Unpacking mplayer2 (2.0-728-g2c378c7-4+b1) ... Processing triggers for mime-support (3.58) ... Processing triggers for man-db (2.7.0.2-5) ... Setting up mplayer2 (2.0-728-g2c378c7-4+b1) ... Is there some other bug for this issue now or should this bug be re-opened? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#769465: improved batch processing workflow
Package: flactag Version: 2.0.4-3 Severity: wishlist Currently, when using the batch mode to operate on many flac files, there is a pause between each file while flactag queries MusicBrainz. The pause can last 5-10 seconds depending upon network conditions and the MusicBrainz service availability. E.g. if the user specifies ten files, then for each file: 1. 5 second pause 2. flactag shows possible match(es) 3. user chooses how to proceed 4. goto step 1 (user waiting 5-10 seconds before interacting with flactag again) This pause between every operation can be frustrating for the user. A better strategy would be: - scan all the flac files mentioned on the command line - obtain all possible data for all of the files from MusicBrainz (maybe with parallel requests from a thread pool for better performance), show a progress bar while this is happening - show a GUI listing each title and allowing the user to quickly move between them in a list or using forward/back buttons Once the user reaches the GUI stage, there should not be any pauses as all relevant data has already been fetched from MusicBrainz. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#685243: breaks squeeze-wheezy upgrade into very bad state
Package: vlc-nox Version: 1.1.3-1squeeze6 Severity: important My box is amd64, running squeeze I started an upgrade to wheezy, apt-get upgrade was successful. Then I ran apt-get dist-upgrade and it failed here: Processing triggers for vlc-nox ... /usr/lib/vlc/vlc-cache-gen: error while loading shared libraries: libvlccore.so.5: cannot open shared object file: No such file or directory dpkg: error processing vlc-nox (--unpack): subprocess installed post-installation script returned error exit status 127 configured to not write apport reports Errors were encountered while processing: vlc-nox E: Sub-process /usr/bin/dpkg returned an error code (1) and now apt-get -f install fails E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. E: Unable to correct dependencies # dpkg --list | grep vlc rc libvlc0 0.8.6.h-4+lenny2.3 multimedia player and streamer library iU libvlc5 2.0.3-1 multimedia player and streamer library ii libvlccore4 1.1.3-1squeeze6 base library for VLC and its modules ii vlc-data 1.1.3-1squeeze6 Common data for VLC iU vlc-plugin-notify 2.0.3-1 LibNotify plugin for VLC iU vlc-plugin-pulse 2.0.3-1 PulseAudio plugin for VLC and full error output: # apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... failed. The following packages have unmet dependencies: amarok : Depends: amarok-common (= 2.6~beta1+75.g47e75df-1) but 2.3.1-1 is installed Depends: amarok-utils (= 2.6~beta1+75.g47e75df-1) but 2.3.1-1 is installed Depends: kde-runtime but it is not installed Depends: libavcodec53 (= 6:0.8.3-4) but it is not installed or libavcodec-extra-53 (= 6:0.8.3-4) but it is not installed Depends: libavformat53 (= 6:0.8.3-4) but it is not installed Depends: libgdk-pixbuf2.0-0 (= 2.22.0) but it is not installed Depends: libkcmutils4 (= 4:4.7) but it is not installed Depends: libkdecore5 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libkdeui5 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libkdewebkit5 (= 4:4.7) but it is not installed Depends: libkdnssd4 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libkfile4 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libkio5 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libknewstuff3-4 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libmtp9 (= 1.1.0) but it is not installed Depends: libmysqlclient18 (= 5.5.24+dfsg-1) but it is not installed Depends: libplasma3 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libqjson0 (= 0.7.1) but it is not installed Depends: libqtcore4 (= 4:4.8.0) but 4:4.6.3-4+squeeze1 is installed Depends: libqtgui4 (= 4:4.8.0) but 4:4.6.3-4+squeeze1 is installed Depends: libqtwebkit4 (= 2.1.0~2011week13) but it is not installed Depends: libsolid4 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed Depends: libtag1c2a (= 1.7) but 1.6.3-1 is installed Depends: libthreadweaver4 (= 4:4.7) but 4:4.4.5-2+squeeze3 is installed brasero : Depends: libbrasero-media3-1 (= 3.4.1-2) but it is not installed Depends: libgdk-pixbuf2.0-0 (= 2.22.0) but it is not installed Depends: libgtk-3-0 (= 3.0.0) but it is not installed Depends: libnautilus-extension1a (= 2.91) but it is not installed Depends: libtotem-plparser17 (= 2.32) but 2.30.3-1 is installed Depends: libtracker-sparql-0.14-0 (= 0.10.0) but it is not installed brasero-common : Depends: dconf-gsettings-backend but it is not installed or gsettings-backend consolekit : Depends: libck-connector0 (= 0.4.5-3.1) but 0.4.1-4 is installed eog : Depends: libgdk-pixbuf2.0-0 (= 2.22.0) but it is not installed Depends: libgirepository-1.0-1 (= 0.9.3) but it is not installed Depends: libgnome-desktop-3-2 (= 3.2.0) but it is not installed Depends: libgtk-3-0 (= 3.3.18) but it is not installed Depends: libjpeg8 (= 8c) but it is not installed Depends: liblcms2-2 but it is not installed Depends: libpeas-1.0-0 (= 1.0.0) but it is not installed Depends: dconf-gsettings-backend but it is not installed or gsettings-backend Depends: gir1.2-atk-1.0 but it is not installed Depends: gir1.2-freedesktop but it is not installed Depends: gir1.2-gdkpixbuf-2.0 but it is not installed Depends: gir1.2-glib-2.0 but it is not installed Depends: gir1.2-gtk-3.0 but it is not installed
