#musicbrainz

Anyone else got a collection on Linux mounted over Samba?

i used to have one, but not anymore

I think that is the cause of the problem I was having yesterday

do oyu have it with many files?

About 100,000

OIC, about 5%

No discernible pattern

i have no idea. and you have those access problems with no other application?

I have checked about 20 files that picard won't accept and other apps have no problem. Gigabit ethernet and 1 terabyte sata drive on fast server

Don't think it's a timeout issue

Always the same files

They all work if I copy them locally, but that is not an option

understandable. you use smbmount to mout the share as a drive, right?

Picard seems happy with them during the drag operation, as it switches the cursor to a +, and it displays them in the left-hand panel. It just seems that it is doing some quick analysis when they are dropped and won't accept them. It can't be the file header itself, as that does not change when I copy the file local. How is it scanning the file when it is dropped?

Windows is mounting the drive an mapping it. I dunno how it does that

Munger: ah, that way .) i thought you were on linux accessing the share

it is only checking the extension

yes, if picard would accept the file but could not read it it would show the file together with an error icon

The drive is in the linux box. MacOS can mount it fine and iTunes accepts everything

Munger: but the files are named like the file you send me?

luks, It obviously checks the extension before it displays it in the files panel. It sees nothing wrong at that point

Munger: i don't think it does that, it checks when you drop

can you start picard with the "--dbug" parameter, then drop that file and paste the output from the debug log somewhere?

Yes. File naming is 100% consistent

that should be "--debug"

Sure. Gimme a few mins

luks: do you have any clue? that does not make much sense

I think it's like "file.mp3 " or "file. mp3" or something like that

munger said he checked that

I do not believe users when debugging a problem (no offence Munger) :)

I understand. If it helps, I was a Mac programmer for over 20 years ;-)

ok, now I believe you a little more :)

But I can still screw up

everybody can that

HEnce my pathological loathing of Windows. I feel tainted

\ø/

WTF!!!! If I run with --debug it accepts them. If I drop that switch and try again it does not. Is somebody having a laugh?

huh

evil debug switch

Munger: where are you dragging the files from?

Hmm. I'm going to keep running it with --debug and see if it starts to fail later. This could be some memory leak that gets progressively worse with use

Munger: but without --debug you can reproduce that right away after starting picard?

In this case, the file view panel in the left of the picard window. It was also failing when I dragged them from windows explorer if the files were on the samba mount,

weird

munger: stupid idea: copy a file that does not work locally and then back to the share and see what happens

Good idea

That might iron out any glitches with character sets

exactly, that was my idea

Hmmm. All working again now. I'm going to throw a few hundred files at it with --debug and watch the logs

Munger: i just tested the file you send me on windows, served from a mounted samba share without --debug. works as expected

if the file is named ". mp3" or ".mp3 " it does not even show up in the file browser on the left as expected

i suggest you use the --debug workaround

It's working for me now - with or without --debug. I started noticing the problem yesterday after about 5 hours of use. I am going to watch and see if it starts happening again

I'll keep the debug switch and hopefully it will catch comething if it happens

ok

I'm sooo happy that the Mac UBs for picard are coming along nicely.

it took only 6 years to deliver on the promise of a mac tagger.

I wonder if Joi Ito will still fork over $500 for finally completing his challenge. :)

I hope he does, then you can spend it all on hookers and blow.

I'd probably just spend it drinking beers with all y'all.

again

I have that album here yet picard won't match it

http://joi.ito.com/weblog/2003/03/07/robert-kay... "...allow the users to force a way to take shift control in the event that something like this might happen" hmm

It damned well should math it. I added the release myself

Oh and, "He is using a sound fingerprint key method to identify the songs." Is that TRMs that he is talking about lol?

munger: get the album manually into picard (use the search functionallity inside of picard) and assign the tracks by dragging them to the new album

Munger: did you use "lookup" or "scan"

?

ruaok: I'm sure there are enough council estate hoochies who wouldn't say no if the price was right!

Both. The puids have tomath, because the release was generated from my files

<3 hoochies

How long does it take to propogate. Maybe it's just waiting for votes or something

munger: there are no PUIDs attached to the release yet (you didn't add them yet, so how should MB now)

ruaok: i'm still wondering what I need to set in pythonpath to run it from the commandline (haven't looked at it properly).

Munger: yes, the search might not yet find it

that was with open Picard.app, right?

Munger: really, just load that release manually into picard (you know the green tagger buttons?)

I use to just drag the release link to picard, but I found out it doesn't work on windows

need to figure out what's wrong

Found it now. I'm still learning to use Picard

luks: yes, i just wondered that too

ruaok: no, 'open Picard.app' doesn't pass on the commandline arguments.

ah.

and this: warp [at peach]:~$ python2.5 /Applications/MusicBrainz\ Picard.app/Contents/Resources/tagger.py ~/music/tmp

gets me this: ImportError: No module named picard.tagger

wow something that is fully replicable. not even path changes needed. that's rare

arp [at peach]:~$ PYTHONPATH=/Applications/MusicBrainz\ Picard.app/Contents/Resources/lib/python2.5 python2.5 /Applications/MusicBrainz\ Picard.app/Contents/Resources/tagger.py ~/music/tmp

that would be my next guess too

but then it can't find qt. which i would've expected are in the default pythonpath.

tagger.py shouldn't be even included in the package

oh, hm.

if Picard.app doesn't pass the arguments, that shold be fixed

luks: how do i start it then?

I don't know, but unless you run from the source tree, you shoudln't be using tagger.py

I get a zlib error.

it's not installed on linux or windows

and I think it shouldn't be on mac either

ok

heh. its kinda needed.

it itself is being used as the script to launch the app.

hm?

it definitely shouldn't be

yeah, if tagger.py isn't there it refuses to load