#musicbrainz

Jugdish__ is now known as Jugdish

Jugdish__ is now known as Jugdish

EtherealShifter is now known as Freso

Ok, the channel is just too quiet. I know it's a Saturday night, but someone say something. :P

something. :P

Oh, I mean...

something. :P

lol

BrianG has changed the topic to: http://musicbrainz.org | http://wiki.musicbrainz.org/CollaborationOfTheM... | Forums! http://forums.musicbrainz.org/ | New Picard rewritten with Qt http://wiki.musicbrainz.org/PicardQt (Version: Alpha 9 ) | FreeDB app gateway active http://freedb.musicbrainz.org

BriaG: might be worth mentioning new a9 out yesterday

How do I sign stuff on the wiki?

@SIG@ isn't working on the preview

afk|raccoonz is now known as aCiD2

it does on save

I see

Do I need the -- ??

nope

ok

lol, I always just manually typed it out :P

btw luks, props- analyze seems to be a lot faster w/a9 vs a8

for what file format? mp3?

all

hm

mainly been hitting the ones that were slowest - ogg and flac

there shouldn't be much difference

at least twice as fast on my system

got some wierd ctd's, but nothing apparent in the log, apart from the one bug report I put in

also looks like the invisible files issue got fixed, though, like I added to my bug ticket, PUIDs aren't submitting

been running a bunch of randomness on it, trying to kill it with anything that used to screw up a8 :)

only guaranteed way to kill a9, or at least, screw it up, is still to hit 0 space left on PicardDrive or SaveFileDrive

four more features, and I'll be a happy camper :) (--> sorting the left side; the menu for char to select replacement char for each invalid char; some cross platform solution to the 0 space issue; and most important, the ability to analyze and submit PUIDs for already ID'd files). :)

but really, props... it's such an improvement over the old picard, and a hell of a lot faster and more stable

sorting is tricky

the UI is a lot more friendly than the old one - just very impressed with the job you've done

no, I mean something different

the default Qt sorting functions will not help me

perhaps just sort on unicode value, avoid language specific sorting issues?

because I need to sort only some branches, not the whole tree

hmmmmm

and extending the tree view in python would be too slow

I always assumed, I guess, that it would sort on artist branch, then album sub-branch

yes, but not tracks for example

do tracks really need to sort?

not in albums

on the right side - yes, exactly

but they do in clusters

which is why it needs custom sorting system

maybe only sort if track # is set in the tags?

(ok, lol, add #5 to my happyness list... some solution for the cluster adding issue re: missing tracks in clusters)

but really, does the cluster side need to sort?

I guess so

The way I use picard, I can ID any file or cluster on the left. It's the unsortedness on the right side which makes matching up files annoying

if you have lots of clusters it can be useful to sort them

well, the way I see it, yes, that is true, but as long as one side is sorted, the task becomes MUCH less difficult to match up the one with the other

plus, tags on the left are normally messy to begin with, so sorting there, apart maybe from artist or release name, isn't all that useful

the track-based sorting you implimented in a9 for clusters seems to work - any way to just keep it, and implement sorting around it?

oh, btw, I haven't updated the bug ticket, but even with the last.fm plugins removed, I'm still seeing that invalid directory notice in the log - removing that one plugin did make a difference though (Picard doesn't crash on load without it, it did crash on load with it)

that notice is ok, it looks for at least three plugin locations

it did crash?

what kind of crash do you mean?

I don't actually use last.fm, but I pulled down the plugin to test it. With the new plug in in the plugins dir, Picard QT either crashes on load, or loads, but I can't do anything w/o a crash.

If I remove it, all is good - I just still see the invalid dir line item in the log.

define "crash" please :)

the usual crash dialog that wants you to send debug info to MS?

Well, nothing works - trying to pull up the about menu, for example - then, in a max of 5 seconds, it closes, with no

"bug happened, written to log" message, and nothing in the log

that's a different log

in the program directory, picard.exe.log

I posted a clean log for it in the bug ticket

there are multiple logs? Only knew about the one in E:\Documents and Settings\Administrator\Local Settings\Application Data\MusicBrainz Picard\logs

E:\Documents and Settings\Administrator\Local Settings\Application Data\MusicBrainz Picard\logs are runtime logs

right

where is the other? I'll check and test

C:\Program Files\<picard>\picard.exe.log is written only if something wrong happens that the program didn't catch

hmmm, let me look...

(e: is windowsdrive on my system, btw)

ah, ok.... that other log may maybe point to the reasons for the two different types of crashes I've seen with a9

actually, looks like 4 different sources for the various crashes I've seen

let me pastebin

ok

ok, 5 types of ctd errors - http://rafb.net/p/gI5JLq12.html

"IndexError: pop from empty list" - http://bugs.musicbrainz.org/ticket/2842

"AttributeError: 'module' object has no attribute 'name'" - last.fm plugin in wrong directory, I guess

and I think the KeyError ones are casused by "IOError: [Errno 28] No space left on device"

well, on the first, that one I couldn't match to any particular issue. 800 mb on each drive, no lat.fm plugin in plugins dir. Only thing I could tie it to was heavy cpu use at load time.

oh, wait

the last.fm one was fixed by deleting the last.fm plugin

the plugin name should be 'lastfm', not 'last.fm'

the others I bypassed by manually matching and savingthe files before the analysis routine ran on them

I left the last.fm plugins with the name as it is on the website, to avoid any such issues

the website says to move them to directory 'lastfm'

the file-based errors, by the way, were with 1 gb on each device at the time

ah, that might be it - I just put them in E:\Documents and Settings\Administrator\Local Settings\Application Data\MusicBrainz Picard\plugins

:P

so you have e.g. plugins/coverart.py plugins/lastfm/__init__.py

?

Do you mean E:\Documents and Settings\Administrator\Local Settings\Application Data\MusicBrainz Picard\lastfm\plugins?

no, nevemind, I'm just too slow :)

lol

just trying to break it (and figure out how it broke) the best I can :)

One other wierdness I've noticed... I'm running a dual cpu system. I don't know if the same would be true of a system with muti-threading, or if PQT even supports multithreading, but it seems too consistant to be anything other...

When I use analyze on load, and load a bunch of files, every other file analyzes, and the "in-between" files never seem to analzye.

hmm

So, say I have 10 files. Files 1, 2, 3, 5, 7, and 9 will analyze, but 4, 6, 8, and 10 never do.

and they stay as 'pending'?

Odd part is, if its the unclustered part, or in a cluster, that first out-of-every-other-pattern file WILL analyze, but only that first will.

So # 2 will analyze, but never 4 6 8 or 10

Kind of seems like it's trying to spawn a second thread, and analyzing the first off the second thread, but never getting a "ok, file analyzed, move on to next file" message for that second thread

yep

but once it moves on to the (next) cluster, that resets, and it again will do one file, but only one file.

This is new, by the way, with a9. a8 always analyzed them all.

oh, then I think I know where is the problem

:)

Don't you just hate the day after you release a new version? :P

Again though, serious props - much better performance, many less crashes, and a hell of a lot better UI than the old Picard

this happens always, I'm getting used to it :)

but that's mainly the reason why I call it "alpha" for now

I mess with the code quite often

lol, well, that's partially why you get such serious props from me for your ability to actually write the thing... It's easy to find faults, and semi-easy to figure out why the faults happen. It's hard to write it in the first place and find a way to fix those faults.

the problem why I introduce new bugs so often is that this basically the complete first GUI program that does heavy background processing I ever wrote

I was having hard time figuring out what would be the best way to do it

hell, new bugs = easy to ID. I'll keep in mind mentioning when they're new to a version if it helps find the source

I wish my skills were still good enough to write it in the first place :P

Even with it skipping files, it does seem to crash a hell of a lot less often on analysis - that actually may be why it seems to analyse so much faster... Easy to manually drag "yet to be analyzed" files from the left to the right when half a release cluster has already been ID'd

However it works, I know I've submitted more PUIDs since yesterday morning that then total I've submitted to MB in the previous 2 years....

I've never crashed writing them to files with the MusicIP util, but I have to wonder about that one - seems a bit odd in that they don

don't save release info or mbid

I did mean to ask you though, about the genpuid util - every time I've tried to run it lately, everything seems to return "invalid"

genpuid never worked for me

Shepard_ is now known as Shepard

it just returns 'unanalyzable' for all my files