This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.
I’m sorry, but I can’t. I had a working OS X build machine, but I don’t remember how it was setup. It was running 10.6 and I had to upgrade to build something else on it. I only managed to upgrade to 10.7 though (the Mac Mini I was running it on is very old), which is not supported by a lot of things either, so I’m afraid I’ll not be able to do a clean install of PyQt4 on the machine.
Ok, @Bitmap said he will try to build the package.
Also there is https://github.com/metabrainz/picard/blob/master/scripts/package-osx.sh
@lukz we may also host the win build system you set up if you give directives to reproduce it (or a docker image).
This topic is no longer a banner. It will no longer appear at the top of every page.
Could we have updated translations in the next Windows build? Having translations in place makes for easier proofreading than on Transifex.
I updated all translations from transifex just now, next build should include them.
Ugraded to the latest available Windows Dev build (1.4.0dev7), and now notice that when enabling the ‘Move Files’ option, the associated files as defined in the settings are not being moved along with the tracks.
I have the ‘Move Additional Files’ option selected in Picard, as it was in 1.3.2, which WAS moving additional files correctly.
Setting Value: *.jpg *.png *.pdf *.zip *.txt *.nfo
Thanks for the report, it is fixed now, see https://tickets.metabrainz.org/browse/PICARD-946
Next win build will include the fix.
You can find the latest macOS build here https://code.oxygene.sk/musicbrainz/picard/builds/1443/artifacts/browse
and the latest windows build here
[quote=“samj1912, post:18, topic:195701”]
You can find the latest build here[/quote]
(tears of joy ;))
Do you have paypal @samj1912?
Just noted that https://tickets.metabrainz.org/browse/PICARD-700 is included in this release, but there do not seem to be any more changes to the source code since I commented on GitHub https://github.com/metabrainz/picard/pull/553 that the proposed changes look to be inconsistent with the existing albumartists field already in use, are you going to update it ?
https://tickets.metabrainz.org/browse/PICARD-700 isn’t included in this release, nor is https://github.com/metabrainz/picard/pull/553. If a consensus is found on it, it may be in 1.4.1, but 1.4.0 is now frozen feature-wise.
oh right, sorry for some reason I thought I saw it listed but must have made a mistake.
The ticket had “fix 1.4” set, but wasn’t resolved/closed, so i guess this is why.
I hope this is the right place to post this. I am encountering some issues and I’d like to figure out why they happen until the stable version comes out. When using lookup/scan, I’m receiving errors very often (tested both 1.3.2 and 1.4 dev7). Trying to lookup/scan 10 releases and on average every 3rd release either doesn’t get identified or is displayed as “could not load album (MBID)” on the right pane. I suspect it might be related to my router, but because currently I don’t have access to it, I can’t try to see what happens when the router is disabled. Is there any other way to figure out if this is indeed an issue with my router? Looking at the log, there are network issues as well as some other issues, for example “UnicodeEncodeError” or if a track contains ’ character, Picard will use " character instead of the ’ character on the “Moving <File u” line (this might be intended, though). In this example case I dropped 10 releases into Picard, clustered them, selected them all and clicked on lookup. 1 release has been correctly named, 4 releases have been correctly identified but not correctly displayed (need right click + refresh) and 5 releases weren’t even matched properly. And sometimes some of the releases will be correctly displayed, but I can’t switch between different releases from the same release group so it seems like the releases are just not properly loaded (and also work after a refresh). Many thanks for helping me investigate this issue.
For what it’s worth, I tagged quite a lot of files yesterday and I had lots of releases that couldn’t be loaded either (not as much as one in three though). I hoped these issues would have been solved with the server move, but apparently not (I also started getting search errors on the website again). So it is more likely to be a server issue instead of a Picard one.
Tried again at 3 am in the morning and this time everything worked fine (20 releases). The “UnicodeEncodeError” is still present, but I guess it isn’t anything serious. I’ll try it again during the day and on wi-fi on monday to figure out if this is a server problem or a problem with my router.
UnicodeEncodeError should be fixed in last versions. It was happening when logging on windows console. The fix will be included in upcoming 1.4.
Glad to hear that. Btw. I haven’t experienced any network issues recently, so I guess the issue I had is now fixed.