Bug#501713: picard: Should be shorthand for $if2(%albumartist%,%artist%)
The usual way to handle this would be to set a variable in the script once, e.g.: $set(_albumartist,$if2(%albumartist%,%artist%)) And then use %_albumartist% in place of the above. If one thinks there should be a special handling of this in scripts this should be reported at https://tickets.metabrainz.org/projects/PICARD/ But to be honest I don't think there should be a special case just for this. There are a lot more commonly used scripting snippets, but adding variables for all of these does not seem very useful. There is a reason why we have the scripting to make it flexible to customize this. I could see however how there could be a plugin providing common shortcuts. On Thu, 09 Oct 2008 20:08:21 +0100 Daniel Watkins < dan...@daniel-watkins.co.uk> wrote: > Package: picard > Version: 0.9.0-4 > Severity: wishlist > > When setting up my rename rules, I've used the string > '$if2(%albumartist%,%artist%)' twice for each entry. It seems like there should > be a short hand for this option, to make working out what's going on easier. > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > > Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages picard depends on: > ii libavcodec51 3:20080706-0.2 library to encode decode multimedi > ii libavformat52 3:20080706-0.2 ffmpeg file format library > ii libavutil49 3:20080706-0.2 avutil shared libraries > ii libc6 2.7-14 GNU C Library: Shared libraries > ii libdiscid00.1.0-1Library for creating MusicBrainz D > ii libfftw3-33.1.2-3.1 library for computing Fast Fourier > ii libgcc1 1:4.3.2-1 GCC support library > ii libofa0 0.9.3-3Library for acoustic fingerprintin > ii libogg0 1.1.3-4Ogg Bitstream Library > ii libraw1394-8 1.3.0-4library for direct access to IEEE > ii libstdc++64.3.2-1The GNU Standard C++ Library v3 > ii libtheora01.0~beta3-1The Theora Video Compression Codec > ii libvorbis0a 1.2.0.dfsg-3.1 The Vorbis General Audio Compressi > ii libvorbisenc2 1.2.0.dfsg-3.1 The Vorbis General Audio Compressi > ii python2.5.2-2An interactive high-level object-o > ii python-ctypes 1.0.2-5Python package to create and manip > ii python-mutagen1.14-1 audio metadata editing library > ii python-qt44.4.2-4Python bindings for Qt4 > ii python-support0.8.6 automated rebuilding support for P > > picard recommends no packages. > > picard suggests no packages. > > -- no debconf information > > >
Bug#941464: picard: Crash when using Spanish locale
Am Di., 1. Okt. 2019 um 09:16 Uhr schrieb Sebastian Ramacher < sramac...@debian.org>: > On 2019-10-01 08:08:21, Philipp Wolfer wrote: > > Package: picard > > > > Version: 2.2.1-1 > > > > Picard 2.2.1 in Buster crashes when using the Spanish locale and > > opening options. This is a bug that we have fixed upstream [1] in the > > 2.1.3 release. > > Do you mean 2.1.2? 2.2.1 is not in buster. > Sorry, my bad. 2.1.2 of course
Bug#583847: picard: allow sorting by album title or artist
Issue can be closed. This functionality had been added in the 0.14 release in 2011 [1] It is working now in current Debian packages. [1] https://picard.musicbrainz.org/changelog/#release-0.14 On Mon, 31 May 2010 03:35:07 + "brian m. carlson" < sand...@crustytoothpaste.ath.cx> wrote: > Package: picard > Version: 0.11-2.1+b1 > Severity: normal > > When I process files through picard for tagging, I am unable to sort (in > the right pane) based on album title or artist. I would very much like > to be able to do that, since sometimes tracks from the same album appear > in multiple editions. > > This is severity normal because although it is a request for a new > feature, the lack of it makes picard *very* difficult to use for > large-scale (approximately 1200 song) tagging. > > -- System Information: > Debian Release: squeeze/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.34-1-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages picard depends on: > ii libavcodec52 5:0.6~svn20100526-0.0 library to encode decode multimedi > ii libavformat52 5:0.6~svn20100526-0.0 ffmpeg file format library > ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib > ii libdiscid0 0.2.2-1 Library for creating MusicBrainz D > ii libfftw3-3 3.2.2-1 library for computing Fast Fourier > ii libgcc11:4.5-20091226-1 GCC support library > ii libofa00.9.3-3.1 Library for acoustic fingerprintin > ii libstdc++6 4.5-20091226-1The GNU Standard C++ Library v3 > ii python 2.5.4-9 An interactive high-level object-o > ii python-mutagen 1.15-2audio metadata editing library > ii python-qt4 4.7.3-1 Python bindings for Qt4 > ii python-support 1.0.8 automated rebuilding support for P > > picard recommends no packages. > > picard suggests no packages. > > -- no debconf information > > -- > brian m. carlson / brian with sandals: Houston, Texas, US > +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only > OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Bug#685102: picard: sends bad requests to server
I think this issue should be closed. This was reported for a very old release and is definitely working in the 2.x releases. If this should be still an issue for anyone this should be brought upstream. Philipp On Thu, 16 Aug 2012 21:29:58 +0200 Johannes Rohr wrote: > Package: picard > Version: 1.0-1 > Severity: normal > > Lately, picard has trouble downloading album data. After dragging some music files (generated and tagged by sound-juicer) to the window on the right, picard instead of displaying the album title displays "unable to load [MBID]" > > Below is an error message from the console: > > E: 140379710048000 21:22:54 Network request error for http://musicbrainz.org:80/ws/2/release/e3f2c3d7-d289-4796-8b4e-407692dea96f; e3f2c3d7-d289-4796-8b4e-407692dea96f?inc=release-groups+media+recordings+puids+artist-credits+artists+aliases+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels: Error downloading http://musicbrainz.org:80/ws/2/release/e3f2c3d7-d289-4796-8b4e-407692dea96f;%20e3f2c3d7-d289-4796-8b4e-407692dea96f?inc=release-groups+media+recordings+puids+artist-credits+artists+aliases+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels - server replied: Bad Request (QT code 299, HTTP code 400) > E: 140379710048000 21:22:54 u'Error downloading http://musicbrainz.org:80/ws/2/release/e3f2c3d7-d289-4796-8b4e-407692dea96f;%20e3f2c3d7-d289-4796-8b4e-407692dea96f?inc=release-groups+media+recordings+puids+artist-credits+artists+aliases+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels - server replied: Bad Request' > > When I look up the album directly on the musicbrainz website instead and click the "tagger" icon, picard retrieves the album data just fine. > > This doesn't happen with every music file, but with many if not most of them. > > -- System Information: > Debian Release: wheezy/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (250, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages picard depends on: > ii libavcodec537:0.10.3-dmo1 > ii libavformat53 7:0.10.3-dmo1 > ii libc6 2.13-35 > ii libdiscid0 0.2.2-3 > ii libfftw3-3 3.3.2-3 > ii libgcc1 1:4.7.1-2 > ii libofa0 0.9.3-5 > ii libstdc++6 4.7.1-2 > ii python 2.7.3~rc2-1 > ii python-mutagen 1.20-1 > ii python-qt4 4.9.3-4 > ii python2.7 2.7.3-3 > > picard recommends no packages. > > picard suggests no packages. > > -- no debconf information > >
Bug#656884: picard: Can't use directories on 'File naming' Options
I think this issue should be closed. This was reported for a very old release and is definitely working in the 2.x releases. If this should be still an issue for anyone this should be brought upstream. Philipp On Sun, 22 Jan 2012 16:48:36 + =?utf-8?q?Lu=C3=ADs_Picciochi_Oliveira?= wrote: > Package: picard > Version: 0.16-1 > Severity: normal > > Hi, > > According to the picard documentation [1,2], it should be possible to define > directories on the "File Naming" Options panel. Music files would then be moved > to those directories according to the defined rules. However, when I define > something like: > > %artist$/%tracknumber% - %title% > > The tracks get named only according to '%tracknumber% - %title%' and anything > before the last slash is ignored. > I used this feature in previous versions and it worked well. I only noticed > this problem on this latest update (from 0.11-2.1 to 0.16-1). > > Best regards, > Luís Picciochi Oliveira > > > 1 - http://musicbrainz.org/doc/MusicBrainz_Picard/Documentation/Options > 2 - http://musicbrainz.org/doc/MusicBrainz_Picard/Documentation/Scripting > > > > -- System Information: > Debian Release: wheezy/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: i386 (i686) > > Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages picard depends on: > ii libavcodec534:0.7.3-2 > ii libavformat53 4:0.7.3-2 > ii libc6 2.13-24 > ii libdiscid0 0.2.2-2 > ii libfftw3-3 3.3-1 > ii libgcc1 1:4.6.2-11 > ii libofa0 0.9.3-4 > ii libstdc++6 4.6.2-11 > ii python 2.7.2-9 > ii python-mutagen 1.20-1 > ii python-qt4 4.9-2 > ii python2.7 2.7.2-8 > > picard recommends no packages. > > picard suggests no packages. > > -- no debconf information > > >
Bug#941464: picard: Crash when using Spanish locale
Package: picard Version: 2.2.1-1 Picard 2.2.1 in Buster crashes when using the Spanish locale and opening options. This is a bug that we have fixed upstream [1] in the 2.1.3 release. I think this package should actually be updated to the 2.1.3 release (which is a bugfix release only not introducing new functionality) or if this is not possible at the very minimum include the patch that fixed the translations [2] [1] https://tickets.metabrainz.org/browse/PICARD-1461 [2] https://github.com/metabrainz/picard/commit/5b7b29df2ae9dd5b860326fc5260e73fde74d0a5
Bug#801278: os-prober does detect Windows 10 as Windows Recovery Environment
2015-10-08 20:20 GMT+02:00 Geert Stappers : > On Thu, Oct 08, 2015 at 06:42:38PM +0200, Philipp Wolfer wrote: > > Actually I wanted to submit a git diff, but I could not figure out where > > the repository can be found. I have found it now, though :) > > Please email that git URL to this (closed) bugreport. > See http://anonscm.debian.org/cgit/d-i/os-prober.git The link to this can be found on the source package page: https://packages.debian.org/source/jessie/os-prober But unless you know where to look it is well hidden ;) Philipp
Bug#801278: os-prober does detect Windows 10 as Windows Recovery Environment
2015-10-08 14:31 GMT+02:00 Cyril Brulebois : > Thanks, Philipp, I've just pushed a release with this patch. > > [ For reference, diff -u is slightly nicer; even better, a git > format-patch would have helped getting proper authoring info to be > directly recorded into git. ] > Thanks a lot for fixing this so fast. Actually I wanted to submit a git diff, but I could not figure out where the repository can be found. I have found it now, though :) Philipp
Bug#801278: os-prober does detect Windows 10 as Windows Recovery Environment
Package: os-prober Version: 1.67 os-prober will detect Windows 10 as Windows Recovery Environment. The following change fixes it for me: os-prober-1.67/os-probes/mounted/x86/20microsoft < if grep -aqs "W.i.n.d.o.w.s. .8" "$2/$boot/$bcd"; then --- > if grep -aqs "W.i.n.d.o.w.s. .1.0" "$2/$boot/$bcd"; then > long="Windows 10 (loader)" > elif grep -aqs "W.i.n.d.o.w.s. .8" "$2/$boot/$bcd"; then
