All times shown according to UTC.

Time Nick Message
00:13 aude left #miro-hackers
00:28 glee joined #miro-hackers
00:38 janetPCF1 left #miro-hackers
00:45 aude joined #miro-hackers
00:52 maggie_s left #miro-hackers
01:23 bendk kcw: you on?
01:23 kcw bendk: yeah
01:23 bendk okay, so I think I finally have a solution that makes sense for check_media_file
01:24 which is, if we find any problem, filename is None, filename doesn't exist, or IO error in read_metadata(), then we do the following:
01:24 set mdp_state to SKIPPED and call check_deleted in an idle callback
01:25 then we can move it back to the constructor
01:25 but it still will delete the file eventually if there's an issue
01:25 and if we set mdp_state to SKIPPED then we know that it's out of the incomplete_mdp_view
01:25 I think that covers all the headaches we were getting
01:25 oh yeah, and fail soft
01:33 willkg: the plan sounds good.  I want to check in one last changeset for check_media_file() before tonight.  Sound okay to you?
01:40 kcw: can you take a look at this one for me when you get the chance?  http://git.pculture.org/miro/c[…]cdb02d362210d5fb2
01:45 willkg: okay, I'm seriously done now
01:45 see you all on the call tomorrow
01:45 bendk left #miro-hackers
02:46 willkg left #miro-hackers
04:50 aude left #miro-hackers
06:39 DGMurdockIII left #miro-hackers
08:42 janet joined #miro-hackers
09:17 maggie_s joined #miro-hackers
09:39 janet left #miro-hackers
09:40 Odysimus left #miro-hackers
09:40 janet joined #miro-hackers
11:18 maggie_s left #miro-hackers
11:19 willkg joined #miro-hackers
11:20 willkg hi!
12:04 CarlFK left #miro-hackers
12:41 CarlFK joined #miro-hackers
13:08 zanoi hmm..i have lots of videos in my music tab :S
13:22 kcw left #miro-hackers
13:23 willkg left #miro-hackers
13:24 willkg joined #miro-hackers
13:52 willkg CarlFK: yay!  i finally got all the pycon2011 videos up except for lightning talks, cosmin's talk (which we only have the first part of), and whatever wasn't in the blip.tv feed.
13:52 CarlFK cosmin or masimo?
13:54 here is part 2 of Cosmin's: http://blip.tv/file/4888662
13:55 willkg funky!  i only have the first part of the cosmin talk (deploying web apps).  i don't have the masimo talk.
13:55 the second part of cosmin's talk probably fell off the edge of the feed.
13:55 i had masimo's talk, though.  so now i'm puzzled as to where it went.
13:56 CarlFK pretty sure there never was a part 2 of mas's
13:56 willkg but one of the first things we posted on PMC was the first part, right?
13:56 CarlFK he said something like "it didn't get recorded"
13:56 right
13:56 willkg so it should be floating around, but i'm not sure where it went.
13:56 CarlFK ah
13:57 willkg i'll put it on the list of mysteries to figure out.
13:57 CarlFK yeah, that's the problem with stuff that is done outside the norm
13:59 willkg afk a bit for food....
13:59 CarlFK "subtitle me" that is so cool :)
14:06 kcw joined #miro-hackers
14:10 z3p good morning
14:31 bendk joined #miro-hackers
14:31 bendk hey all
14:31 kcw: did 0daadda look okay to you?
14:32 kcw bendk: yeah, that looks good.
14:41 ajonas joined #miro-hackers
15:00 bendk willkg: can you peer-review these commits?
15:00 http://git.pculture.org/miro/c[…]h=fixes_for_17345
15:01 http://git.pculture.org/miro/c[…]b430077710cd36261
15:02 willkg both of those look ok.  does the 2d4e5d9 affect crash reporting?  does bd work correctly?
15:05 bendk It seems like it does to me
15:05 I sent a crash report and it looked good
15:05 https://bogondeflector.pcultur[…]1740a1/1305125119
15:05 willkg ok.  if it works, i'm game.
15:06 bendk okay, moving them to master
15:11 aude joined #miro-hackers
15:55 aude left #miro-hackers
15:55 Odysimus joined #miro-hackers
16:02 willkg dev call notes: http://bluesock.org/~willg/blo[…]all_20110511.html
16:02 afk a smidge.  then i'll start rolling rc1.
16:24 Odysimus left #miro-hackers
16:25 aude joined #miro-hackers
16:39 Odysimus joined #miro-hackers
16:41 Odysimus left #miro-hackers
16:42 z3p deardiary: unless something comes up, going to be spending the day trying to reproduce device crashes
16:42 Odysimus joined #miro-hackers
16:50 zanoi kcw, i'm getting my ogg/ogv files classified wrong. Should I create a new bug or should I add the info to one of the existing audio video classification bugs?
16:51 kcw zanoi: I don't think that's related to any of the previous issues
16:51 zanoi kcw, ok
16:52 kcw zanoi: actually I think it is
16:52 zanoi kcw, which bug?
16:52 kcw in #16436 we discussed how to handle OGG's extension-weirdness, so I guess it's part of that
16:53 zanoi ok i'll add it there
17:04 willkg z3p: you on?
17:05 z3p: is bca6ab0 safe to go in the rc?  has it been tested well?
17:07 z3p willkg: let me see which one that is
17:09 willkg: it shouldn't cause any crashes; I've been trying to get device crashes all morning and only got the one I fixed in the next checkin
17:09 willkg z3p: ok.
17:09 z3p: i just submitted a new bug for a crash i keep getting.
17:10 z3p willkg: yeah, I can't reproduce that one either, but I'm poking at stuff as much as I can
17:10 willkg z3p: i've seen it for the last few days.  i submitted a bunch of crashes to bd yesterday.
17:10 z3p: after i do the rc, i can poke around at it more.
17:11 z3p willkg: can you attach your JSON file? or even just e-mail it to me?
17:12 I don't even see how description can get '' as a value
17:13 willkg z3p: it's on its way!
17:13 z3p: by email.  it's a 2.2mb file.  figured that'd suck for bugzilla.
17:13 i'm tagging rc1 now.
17:15 z3p wtf simplejson
17:17 bendk willkg: I just found two fairly bad bugs, that I can easily reproduce
17:17 I don't know if the fixes need to be in for the RC or not
17:18 the bugs are: 17354 and 17358
17:19 willkg bendk: mmm...
17:19 bendk: i only just tagged.  so my vote is you do things and i'll re-tag.
17:20 bendk okay cool
17:20 I think it'll be less than an hour
17:21 willkg ok.
17:21 ping me when you're ready.
17:21 z3p willkg: I should be able to get a fix in for your bug, too
17:21 willkg as a side note, i just totally screwed up and accidentally deleted the master branch.
17:21 but then i fixed it!  git ftw!
17:21 z3p: if you could, that'd be super fantastic!
17:21 z3p: it prevents me from playing White Zombie during the release process.
17:23 z3p willkg: oh noes!
17:24 willkg: it looks like json.load() isn't always giving us dictionaries with unicode keys/values
17:24 willkg z3p: awesome!
17:24 i thought you were saying "oh noes!" because i deleted the master branch and (possibly) didn't fix it right.
17:25 z3p willkg: no, I meant the white zombie
17:25 willkg ahh...  whew.
17:28 z3p willkg: with git, I wasn't worried about deleting master
17:28 * willkg nods.
17:28 willkg i was being stupid.  i saw --delete in the git push help and i wondered, "i wonder what this does...  oh, man!  i just deleted master!"
17:30 z3p willkg: I just checked in d513ec6. I couldn't reproduce the issue myself, but I'm pretty sure it'll fix it
17:30 willkg can't figure out how to delete the tag on g.p.o.
17:30 z3p willkg: I don't think you can do it remotely, but you can always SSH in and remove the tag from the directory
17:30 willkg pretty sure i've done this before.
17:31 z3p: that looks like it works much better.
17:31 z3p: but now i get a different issue.
17:32 z3p neat!
17:32 willkg z3p: http://pastebin.me/97c476d4442[…]29328084f1a00584b
17:32 bendk one down
17:32 willkg bendk: yay!
17:32 bendk willkg: can you peer-review f7a8cb1
17:33 I'm not sure if the call to check_media_file() is needed, but I thought it was good just in case
17:34 willkg bendk: so...  if it calls make_undeleted, then it'll log a warning.  but i think we can nix the warning.
17:34 bendk: i think i'd put the logging.warn into an else: block.
17:35 bendk I agree
17:36 z3p willkg: I'm installing py2.7 right now; I'll see what happens
17:37 willkg bendk: we might also want to set the downloadedTime.  do we do that for local files?
17:39 bendk we set it to None in setup_new()
17:39 so I'm not sure why we are setting it to None is make_deleted(), but I left that code around
17:39 willkg bendk: ahh...  ok.
17:39 bendk on second thought, I think we should either keep the warning always or just remove it entirely
17:39 willkg i think we should set downloadedTime to datetime.now()
17:40 bendk we show that warning if you do open a file that's already in the DB with miro
17:40 willkg the duplicate warning?  i think i may have put it there just so i could see what was going on.
17:40 bendk I'm okay with just removing it altogether
17:40 I just don't think it makes sense to distinguish based on deleted
17:40 z3p doesn't work well on maverick; time to get a natty vm
17:40 willkg i think i'd rather we moved the warn to a debug.
17:40 er, switch the logging.warn to a logging.debug.
17:41 it's nice to be able to see what's going on when doing dev stuff.
17:41 bendk yeah, debug sounds the best
17:42 z3p willkg: so I don't think I can install natty in a VM, then debug and solve your issue in <1 hour
17:42 willkg looks like the downloadedTime affects some of the filters/views or something like that.  so i'd set that, too, in make_undeleted.
17:42 otherwise it looks ok.
17:42 z3p willkg: which error do you like better?
17:42 willkg z3p: heh.  i'm not sure.
17:42 z3p: you think it's a 2.7 related issue?
17:43 bendk willkg: are you saying change this for the RC?
17:43 willkg bendk: yeah.  they're two small changes.
17:44 bendk The debugging one seems fine, I'm a little worried about downloadedTime
17:44 actually, no I'm not
17:44 willkg it gets set to datetime.now() in one of the downloading methods.
17:44 bendk I'm okay with making that change, although I'm not sure why not wait on it
17:44 willkg seems pretty safe.
17:44 well, i'm waiting on other things right now, right?
17:45 bendk but this is for FileItems, so it currently should always be None
17:45 willkg hrm.  that seems icky to me.  but that's ok.
17:45 kcw this bug has just come up (#16436#c23) where we're miscategorizing about half of videos that have ".ogg", because mutagen is telling us videos are audio
17:47 the simplest fix is to run MDP anyway whenever mutagen tells us an ogg is audio, though that's bad for import performance
17:48 z3p willkg: I can't reproduce your issue with 2.6
17:48 kcw I think it could wait for after the RC, but it seems kind of serious if we're really miscategorizing 50% of .ogg videos
17:48 so I'm not sure
17:49 willkg z3p: i'll see if i can reproduce it.
17:51 z3p: also, i'm psyched you fixed the item name problem.  i was tossing around creating a bug for it, then didn't.
17:51 bendk: you're still working on a bug, right?
17:52 bendk yup
17:52 I'm pretty close on it
17:53 willkg ok.
17:56 z3p: yeah, i can reproduce it.
17:56 z3p: i'll write up a bug for it.
17:57 z3p willkg: I think I might have a lead on it too
17:58 bendk willkg: so I have a fix for #17358, but I'm not sure if I should try for a less invasive one
17:58 here's what I want to do:  http://dpaste.com/541265/
17:58 and basically here's the error:
17:59 we have a torrent folder in a feed
17:59 the user deletes the folder
17:59 willkg z3p: i wrote up steps to reproduce.  it's bug 17359.
17:59 bendk this calls expire() on the folder, which calls delete_files() for all its children
17:59 but the children stay in the database, even though their files are deleted
18:00 so when we restart, we realize that, then try to call expire() on the children, but that causes all kinds of problems, because the parent knows it's deleted its folder, so isContainerItem is set to False
18:02 z3p willkg: if you search for that file, do you see it twice in the tab?
18:02 willkg z3p: it's only in the view once.
18:03 i'll search on the drive, though.
18:04 z3p: it's only on the drive once.
18:04 z3p: i have a bunch of music that's on the drive multiple times, but that song isn't one of them.
18:04 bendk: so...  calling self.remove() fixes that how?
18:05 bendk calling self.remove() removes the item from the database
18:05 so it fixes both consistency problems
18:06 there's no longer an item with parent_id set to something with isContainerItem=False
18:06 willkg which item is this affecting, though?  the container item?
18:06 bendk oh, that's itended for the child items
18:06 willkg ok.
18:07 bendk: i think it makes sense.  but i don't know this code very well, so i'm not sure how useful that is.
18:08 bendk yeah, me neither that's the problem :)
18:08 I'm going to check in one that targets this specific bug more
18:09 I think the other change is good, but I want to wait on it
18:09 * willkg nods.
18:09 z3p willkg: I can't reproduce the crash, but something bad is definitely happening
18:09 willkg z3p: ok.  it seems like it's only crashing on that one item.
18:10 z3p: i'll delete the item and see if it still happens.
18:11 z3p: so, it does happen again, but with a different item.
18:11 z3p: it's an info_list thing...  maybe bendk should look at it, too.
18:11 i'm game for pushing out an rc with this bug, though.
18:13 z3p willkg: does the other item also have a ' in it?
18:13 willkg: or possibly a unicode character?
18:13 willkg i don't know.  it's got some kind of unicode character in it.
18:14 F200 or F020.  i can never remember which way to read the hex digits in the box thing.
18:15 bendk willkg: okay, just pushed a fix
18:15 http://git.pculture.org/miro/c[…]a7636822dd2f6ece3
18:15 z3p willkg: what's happening is that the DB getting the item twice; once with a Unicode ID and onces with a UTF8 string id
18:15 willkg z3p: icky!
18:16 z3p willkg: very icky
18:16 willkg: so now, I just need to figure out where that's coming from and fix it
18:16 but progress!
18:16 willkg z3p: is this something that should block an rc?
18:16 if it's non-ascii char related, i think maybe it should.
18:16 bendk: that looks good to me.
18:17 z3p willkg: give me 10m to check all the obvious places
18:17 willkg z3p: no problem.  ping me when you feel differently.
18:18 i'm going to go get something to eat.
18:18 afk a smidge.
18:18 bendk okay, I'm happy with pushing out the RC then
18:26 z3p willkg: try master; if it works for you then I'm good
18:26 there's some other stuff I should fix, but I'll do it after the RC
18:36 willkg z3p: i'm testing it now.
18:41 z3p: also, since your process changes, i periodically get ProcessHung: http://paste.pocoo.org/show/387060/
18:43 z3p: i'll turn that into a bug, too.
18:50 z3p: i still get the problem.
18:50 z3p willkg: grumble
18:50 willkg sorry dude.
18:51 i think i'm going to call it.  i'm going to retag now and start doing the rc process.
18:51 z3p, glee, zanoi, kcw, bendk: is that ok with all you?  do you need me to wait?
18:51 z3p willkg: not your fault; it's just frustrating for me to have all these outstanding bugs that I can't reproduce
18:51 willkg: go for it
18:52 glee I'm good.
18:52 kcw willkg: I don't have anything that should block an RC
18:53 zanoi i'm fine
18:53 bugs marked "critical" don't necessarily have to be in the RC right?
18:54 willkg zanoi: correct.  only blockers.
18:54 ok.  i'm tagging now.
19:06 tagged.
19:06 making builds.  then i'll smoke test them.  then i'll pass them to janet to test.
19:06 janet yay RC
19:07 willkg janet: sorry this is taking so long.
19:08 janet: we decided to rewrite it in befunge.
19:08 janet I'm refusing to understand you
19:09 it's been a long week –  I never want to see my music files again.  I keep looking at the calendar, thinking that we will get there soon.
19:09 and drinking massive amounts of green tea - after the morning coffee.
19:10 i feel so pixelated.
19:14 willkg i hear that.
19:17 i think that's one of the big advantages you and z3p have: when you're sick of one PCF project, you can just go work on another for a while.
19:46 paroneayea joined #miro-hackers
19:48 willkg janet: miro 4.0 rc1 builds are posted on the nightlies page.  can you take them for a quick spin just to make sure we're ok?
19:49 janet: i did a smoke test to make sure they had the right version number already.
19:52 janet: ping me when you think they're ok.  then i'll figure out how to do a release announcement with a proper delta from the beta.
19:56 z3p left #miro-hackers
19:58 z3p joined #miro-hackers
20:03 willkg z3p, zanoi, bendk, glee, kcw: i pushed out rc1, so we can check into master again.
20:24 janet ok willkg
20:24 downloading now
20:29 zanoi kcw, how timeexpensive is a call to item.check_media_file() (a. k. a. mutagen)?
20:29 kcw zanoi: I'd estimate it takes about 1/10th of a second - it's fast enough that we do it in setup_new
20:30 janet left #miro-hackers
20:30 zanoi kcw, ok, thx
20:32 kcw actually, I think it's quite a bit faster than that on average. You can see get a feel for its timing when you add a directory of audio files.
20:33 janet joined #miro-hackers
20:37 willkg deardiary: going through the four gazillion bugs for 4.0 and cleaning up the bug data so the release notes aren't crazy.
20:37 but first...  afk for a drink.
21:07 janet better drink alot - there's > 1000 bugs.
21:11 willkg janet: yeah.  i'm going through them.  slowly.  and in shifts.
21:14 janet left #miro-hackers
21:15 janet joined #miro-hackers
21:21 aude left #miro-hackers
21:21 aude joined #miro-hackers
21:55 zanoi what is the best way to determine whether an item has a file associated with it?
21:56 should I check whether the filename exists or is there a better attribute?
22:01 janet left #miro-hackers
22:02 ajonas left #miro-hackers
22:02 janet joined #miro-hackers
22:03 ajonas joined #miro-hackers
22:04 ajonas left #miro-hackers
22:04 kcw zanoi: Item.filename is probably not a good indicator of that. What are you really trying to determine?
22:08 zanoi kcw, whether a file exists to run check_media_type() on, because it seems to cause an exception otherwise
22:17 maggie_s joined #miro-hackers
22:47 bendk taking of for today, see you tomorrow
22:47 bendk left #miro-hackers
23:14 janet this one is a pretty glaring regression: http://bugzilla.pculture.org/s[…]_bug.cgi?id=17362
23:14 but I've overstayed my usefulness for today and I'm going to sleep.

← Previous day | Index | Server Index | Channel Index | Today | Next day → | Atom Feed | Search | Google Search | Plain-Text | plain, newest first