[01:30] <queuedman> Hi, anyone here have any issues with music downloads staying in "Queued.." state?
=== Othercirick is now known as Cibort
[03:28] <FiReSTaRT> queuedman: i do
[03:29] <FiReSTaRT> queuedman: just came here to ask about it lol
[03:29] <FiReSTaRT> my sync is also stuck at 0 while it worked like a charm before i tried buying a song
[03:31] <FiReSTaRT> queuedman: it might have something to do with this bug https://bugs.launchpad.net/ubuntu/+source/rhythmbox-ubuntuone-music-store/+bug/596394 i'm not sure,b ut check it out just in case
[03:31] <ubot4> Launchpad bug 596394 in rhythmbox-ubuntuone-music-store (Ubuntu) (and 1 other project) "False "Internet connection is required to access the music store" message (affects: 11) (dups: 1) (heat: 38)" [Undecided,New]
[03:32] <FiReSTaRT> plus rhythmbox crashes on restart
[03:33] <FiReSTaRT> wow.. FINALLY download complete after like 10 restarts :O
[11:27] <karni> aquarius: Do you know why a single file modification causes server to broadcast 4 consecutive generations, while a folder rename causes only 1 generation broadcast? Or should I defer the question to verterok, too?
[11:28] <karni> aquarius: perhaps gedit uses some cache file. let me check that a lil bit smarter (just appending something to a file)
[11:29] <rye> karni, gedit does atomic save, save to temp, remove, rename
[11:29] <rye> karni, and good morning!
[11:29] <karni> rye: hello rye!
[11:30] <karni> rye: that would be 4 changes.. so it saves to a new file each time, is that right?
[11:31] <rye> karni, hm, not sure about 4, first it saves to temporary file name, then unlinks the original one, then renames the temp file to original name, as far as I remember
[11:31] <karni> probably appending to file with cat >> would not generate 4 generations then.
[11:31] <karni> rye: thanks, that's definitely useful info
[11:31] <duanedesign__> hello rye and karni
[11:31] <karni> hi duanedesign__
[11:31] <rye> duanedesign__, morning!
[11:31] <karni> morning everybody :)
[12:02]  * mandel -> walking dog
[12:09] <ralsina> good morning everyone
[12:25] <pazo> any devs online?
[12:25] <Chipaca> some
[12:26] <Chipaca> pazo: what's up?
[12:26] <pazo> I've bought a song but the status keeps being "Queued..."
[12:27] <Chipaca> pazo: can you see it on the web under files?
[12:27] <pazo> nope
[12:27] <pazo> It's really odd
[12:28] <pazo> and file sync is working
[12:28] <Chipaca> hmm
[12:28] <Chipaca> rye: ping
[12:29] <rye> Chipaca, pong
[12:29] <pazo> Searching the web, shows some examples of similar type but not with a solutuin sadly :(
[12:29] <rye> pazo, syncing logs and looking
[12:29] <Chipaca> pazo: can you hang around for about half an hour more? east coast of usa will be working then (and I think this is one for somebody there)
[12:30] <Chipaca> pazo: meanwhile, rye is on it :)
[12:30] <pazo> Yep. No problem!
[12:30] <pazo> Cool
[12:30] <Chipaca> now, stopping for a bit to have breakfast with my kids
[12:30]  * Chipaca waves
[12:43] <duanedesign__> rye: if you get a chance. Couldd you take a look at this post, specifically the screenshot. I was wondering if you might have a guess to the problem. http://ubuntuforums.org/showthread.php?t=1662534
[12:47] <rye> duanedesign__, it looks like desktopcouch cannot be contacted for some reason which disables these items
[12:49] <duanedesign__> ahh, ok that would cause that..ok
=== teknico is now known as teknico_away
=== zyga_ is now known as zyga-breakfast
[13:52] <ralsina> CardinalFang, vds I think I'll postpone the standup until the people that's at the sprint show up
[13:53] <vds> ralsina: sure
[13:53] <ralsina> But if you need anything, I am not there, so I can help ;-)
[13:54] <CardinalFang> This is a Dallas sprint?
[13:55] <pazo> I've bought a song but the status keeps being "Queued...". Anyone who can help?
[13:55] <CardinalFang> ralsina, of desktopcouch, btw, I found and fixed three bugs Friday / Saturday.  Landing them and releasing today, I promise.
[13:56] <ralsina> CardinalFang: oh, great
[13:57] <mandel> ralsina: when will that be, I mean the standup?
[13:57] <ralsina> mandel: I am thinking in 3 hours?
[13:57] <ralsina> I hope that's not too early dallas-time
[13:57] <vds> rye: pazo has problems with a song he bought can you help him?
[13:57] <mandel> ralsina: ok, I might be able to make it, my dogs has some problems and I've got an apponintment with the vet
[13:58] <mandel> here +3 == 6pm :P
[13:58] <pazo> vds: he seems to be AFK
[13:58] <ralsina> mandel: if you don't just past it to me in private and I'll post it in your behalf :-)
[13:59] <mandel> ralsina: ok, I'll give yu the status as late as possible so that it is up to date
[13:59] <ralsina> mandel: cool
[14:04] <Chipaca> pazo: we're working on it right now
[14:04] <Chipaca> pazo: sorry for the delay :-/
[14:09] <pazo> No problem. :) Going afk for 1 hour
=== teknico_away is now known as teknico
[15:16] <joshuahoover> ralsina, Chipaca: fyi...bug #673568 is causing maverick users to not be able to edit contacts in evolution...rye has been in touch with rodrigo about it but i don't think you guys were aware of this...kind of bad bug
[15:16] <ubot4> Launchpad bug 673568 in evolution-couchdb (and 1 other project) "Error modifying contact, other error when saving contacts (affects: 29) (dups: 4) (heat: 142)" [High,In progress] https://launchpad.net/bugs/673568
[15:17] <ralsina> joshuahoover: yes, I had seen it, but after rodrigo was on holiday thanks
[15:59] <toml> hey all
[15:59] <toml> got some trouble with contact sync
[16:00] <toml> duplicate madness
[16:00] <toml> on Ubuntu One
[16:05] <ralsina> CardinalFang: kenvandine offered help with packaging desktopcouch if you need it
[16:11] <CardinalFang> ralsina, I don't think I do.  The packaging is pretty easy.  Thanks, kenvandine.
[16:12] <CardinalFang> if kenvandine wants to maintain "upstream" project, I'd take that, ha ha.
[16:13] <ralsina> hahaha
[16:16] <kenvandine> CardinalFang, no way :-p
[16:16] <CardinalFang> Dang.
=== beuno is now known as beuno-lunch
[16:22] <ralsina> mandel, vds, CardinalFang: Looks like I have to go to the bank, so no standup today guys
[16:23] <ralsina> Bright side, you will look much more productive tomorrow
[16:23] <mandel> ralsina: as you wish :)
[16:25] <vds> :)
[16:35] <karni> hi (again) everyone
[16:35] <karni> aquarius: verterok: thank you for your mail response
[16:35] <karni> aquarius: lemme know when you have a moment to talk
[16:35] <aquarius> karni, go for it
[16:35] <karni> great
[16:35] <karni> aquarius: i'd like to talk the selective sync for a moment
[16:36] <aquarius> ok
[16:36] <karni> aquarius: main issue is that, since files are replaced instead of 'changed' (as a regular user would percieve)
[16:36] <karni> it'd take some skill/neat idea to cache those generations bumps and sync only when necessary not to loose the info about being a fav item
[16:37] <karni> however, it's not that easy. imagine a user has the service working on the phone at the moment
[16:37] <aquarius> karni, but that's fine, if you're storing (folder id, path) as the key for favourites, as we discussed?
[16:37] <karni> somebody changes a file in a share...
[16:37] <karni> aquarius: lemme finish, that works - but only for "invoked sync", rather than callbacks in realtime
[16:38] <karni> aquarius: the point is that, once we say 'hey, sync now' and we fetch some newer generation, that solution works fine
[16:38] <karni> and we don't loose that fav info
[16:38] <hrw> hi
[16:39] <karni> however, that works because we (possibly! that's not sure) have just jumped over that step 'file removed / file created'
[16:39] <karni> aquarius: to be precise, let me rephrase
[16:39] <karni> aquarius: we don't loose the fav info, if the delta for given generation contains, at the same time, 1. file deleted 2. file created -- that works fine
[16:39] <hrw> someone can tell me which exaclty packages I need to have installed to get u1 working in non-gnome?
[16:39] <karni> as I just update some values (nodeId, hash, etc)
[16:40] <aquarius> karni, just don't delete things from the favourites list, *even if* the file is deleted
[16:40] <karni> aquarius: why didn't I think about that xD
[16:40] <aquarius> if the worry is that eventually the favourites list will get too big, then run a cleanup job on it when it gets too big and remove the oldest items which aren't there any more
[16:41] <karni> aquarius: this is just a column in the main 'files' table to avoid unnecessary joins
[16:41] <toml> anyone around from the One team?
[16:41] <karni> however, that is sufficient.. right. I'll remove the old file copy if I receive isLive=false, but not the meta.
[16:41] <CardinalFang> Plenty.
[16:41] <toml> aha
[16:41] <toml> good good ...
[16:42] <karni> aquarius: that way I can update it in the future with the new file, and it'll still be favourite. that makes sense.
[16:42] <toml> so, funambol
[16:42] <CardinalFang> Ick.
[16:42] <toml> is creating duplicate contacts
[16:42] <toml> ...now, this is from within Thunderbird
[16:42] <toml> (i know, i know, it's not supported in v 3)
[16:42] <CardinalFang> And that's a shame,  V3 rocks.
[16:42] <toml> it does
[16:42] <toml> it's a great improvement
[16:43] <toml> v3 has  dragged me back to it in fact
[16:43] <toml> but
[16:43] <toml> sync is required
[16:43] <karni> aquarius: lastly, i'd say (parent id, filename) instead of (parent id, path). that's shorter, and sufficient.
[16:43] <toml> any ideas on how to get tbird syncing with couchdb etc
[16:44] <aquarius> karni, does every folder have a folderid, or just UDF top-level folders? I wasn't sure about that, which is why I wasn't sure and passed it over to verterok :)
[16:44] <rye> toml, i think I can create a simple exporter from CouchDB contacts to vcard format...
[16:44] <toml> rye, hey
[16:44] <rye> not autosync though
[16:44] <verterok> aquarius: yes, every node have a node_id (and directories are nodes ;) )
[16:45] <karni> aquarius: any folder (equally, parent of a file) has a nodeId that doensn't change, even upon folder rename
[16:45] <toml> yeah, the autosync's gotta be the long term aim I guess
[16:45] <karni> verterok: perfect explanation :)
[16:45] <aquarius> toml, JamesTait has been working on Thunderbird contacts sync with Ubuntu One (not using Funambol, but working directly with CouchDB), but I don't know what stage that's at
[16:45] <toml> rye, the thing is that the funambol plugin seems to mostly work
[16:45] <toml> aquarius, I've tried out that ... doesnt' work with tb 3
[16:46] <toml> aquarius, hedera's the name
[16:46] <aquarius> toml, yeah, I was just attracting JamesTait's attention in case he said "I've fixed that in a branch" or something :P
[16:46] <karni> aquarius: ok, last question then (because this is seriously better sonner then later ;) )
[16:46] <JamesTait> I have not finished that in a branch. :)
[16:46] <rye> wow
[16:46] <toml> JamesTait, hey man - tried out your plugin
[16:47] <rye> JamesTait, that is awesome!
[16:47] <karni> aquarius: looking from volumes perspective, this task is trivial. syncing a volume is like any sync in U1 - isLive=false? fine, delete file. isLive=true? great, download it.
[16:47] <toml> JamesTait, thanks for putting it together ... def meets a need, but does't play well with v3 on firefox
[16:47] <toml> JamesTait, that's Thunderbird, not firefox  oops
[16:48] <JamesTait> toml :) I guessed that.
[16:48] <karni> aquarius: however making only volumes syncable - we loose the grantulity of the sync to file level. i.e. you wouldn't be able to sync a single file from a volume, which sounds like a cool feature.
[16:48] <toml> JamesTait, just acknoledging my idiocy ;)
[16:48] <karni> aquarius: (i.e. sync only this UDF, that UDF, and this Share)
[16:48] <toml> JamesTait, are you thinking of carrying on work in the plugin?
[16:49] <hrw> someone can tell me which exaclty packages I need to have installed to get u1 working in non-gnome?
[16:49] <JamesTait> toml: I'm working exclusively on TB3 now, unless someone asks for TB2 in which case I'll invite patches. :)
[16:49] <aquarius> karni, yep, OK
[16:49] <aquarius> hrw, I'm not sure, but I imagine that rye will know :)
[16:49] <toml> JamesTait, ah cool ... you making progress?
[16:50] <JamesTait> toml: Work has begin again the last week or so, and progress is being made, yes. :)
[16:50] <rye> hrw, you will need to have ubuntuone-client, it will bring the dependencies such as gnome-keyring with it (well, depending on the version though)
[16:50] <toml> JamesTait, so I'd better just cut to the chase: eta on an update?
[16:50] <karni> aquarius: that ACK means exactly.. ? should we stick to file-level sync, or volume-level sync (which is trivial, and more desktop syncdaemon like)?
[16:51] <hrw> rye: natty
[16:51] <JamesTait> toml: I'll be landing a branch very soon that adds some UI elements for visual feedback and to enable/disable debug via preferences.
[16:52] <JamesTait> toml: Very soon being today or tomorrow, most likely.
[16:52] <rye> hrw, ubuntuone-client will bring everything in. ubuntuone-client-gnome provides nautilus and preferences applets
[16:52] <aquarius> karni, ah, that wasn't an ACK, that was "I understand what you've said, thus far". I, personally, do not believe that turning on sync for a whole UDF is a good idea on Android. I think favourites should be files only, or maybe files and folders, but not a whole UDF. But I'm open to suggestions from beuno on that; I can see an argument for UDF-level sync (specifically, I create a UDF named "sync to my phone", and
[16:52] <hrw> rye: I have both
[16:52] <aquarius> then drop things in it to have them appear on my phone with no effort)
[16:53] <karni> aquarius: oh good, sorry. I'm glad you expanded on that :D
[16:53] <hrw> State: READY
[16:53] <JamesTait> toml: Pushing contacts is failing in some circumstances at present, so that's next. I haven't investigated so I don't know how big a problem it is.
[16:53] <hrw>     connection: Not User With Network
[16:53] <hrw>     description: ready to connect
[16:53] <hrw>     is_connected: False
[16:53] <hrw>     is_error: False
[16:53] <hrw>     is_online: False
[16:53] <hrw>     queues: IDLE
[16:53] <hrw> thats what u1sdtool -s says
[16:54] <toml> JamesTait, ah very cool indeed James. I think it's a key missing piece in the puzzle for ubuntuone - you going to be updating through launchpad?
[16:54] <hrw> ~/.config/ubuntuone/ dir is empty
[16:54] <JamesTait> toml: Absolutely. :)
[16:54] <toml> JamesTait, okay, great ... will test for you on it
[16:54] <JamesTait> toml: Fantastic, I can use all the feedback I can get!
[16:55] <hrw> btw - bug 701099
[16:55] <ubot4> Launchpad bug 701099 in ubuntuone-android-contacts "Ubuntu One Contacts should use Ubuntu logo (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/701099
[16:55] <toml> JamesTait, okay, I'll watch for it. Thanks for the update.
[16:55] <karni> aquarius: ok then, thanks a bundle. I'll wait for beuno-lunch to speak his mind on the topic. however, looks like file-level sync is more resonable from a user's perspective
[16:56] <aquarius> karni, I like the idea of having a UDF I can just drop things in, though. Can you reasonably easily calculate the size of a UDF?
[16:57] <aquarius> karni, so that if I favourite a UDF you can check the size and say "that'll sync 12GB to your phone; are you sure you want to do that?"
[16:57] <karni> aquarius: AFAIK we get the file synce once we download that, but I'll double check if it's not in the delta. if it is, that'd be possible. 1 sec
[17:00] <JamesTait> toml: The UI elements piece got brought forward, because I got quite a few questions along the lines of "I installed it, how do I know it's installed/working?"
[17:00] <karni> aquarius: I meant *size. I see that the size is provided in the delta, which would mean yes. however, since I don't display the size until the file is downloaded - I must have had a reason for that. I'm looking at the sources.
[17:03] <rye> hrw, u1sdtool --connect ?
[17:04] <hrw> rye: did that few times. problem is that u1 is still not configured
[17:04]  * hrw goes to search for note taker which uses dropbox or ssh/sftp
[17:05] <JamesTait> toml: but work basically stopped around September due to lack of time, until last week or so. I'm actively hacking again now.
[17:05] <rye> hrw, by not configured - was it prompting you to register?
[17:05] <hrw> rye: no, it didnt. thats the problem I think
[17:06] <rye> hrw, ok, could you please check whether you have ubuntu-sso-client installed?
[17:06] <hrw> rye: 1.1.7-0ubuntu1 is present
[17:07] <toml> JamesTait, aye, it's hard enough making these things off your own back anyhow, so I appreciate the work ...
[17:08] <rye> hrw, ok, could you please try running env DEBUG /usr/lib/ubuntu-sso-client/ubuntu-sso-login
[17:08] <rye> ?
[17:11] <hrw> 11:10 hrw@lucek:.config$ DEBUG=1 /usr/lib/ubuntu-sso-client/ubuntu-sso-login
[17:11] <hrw> Ubuntu SSO login manager already running, quitting.
[17:11] <hrw> killed, restarts
[17:12] <hrw> rye: http://hrw.pastebin.com/D7xC79zm is effect of running it and "u1sdtool -c" in other shell
[17:13]  * hrw installs gnome-keyring by hand
[17:13] <hrw> now it works...
[17:15] <hrw> for years I thought that Debian packages have proper dependencies. looks like it does not applies to Ubuntu packages
[17:15] <karni> aquarius: so: FileInfoDelta (item in a requested delta) does have a method getSize(). However, initially it returns zero. I fetch the file size from getContent request, nodeAttr.getSize() -- that'd mean we only know the size of downloaded files.
[17:15] <karni> verterok: Should a FileInfoDelta contain a proper size of a file? (it does have a getSize() method, but it returns 0 )
[17:16] <karni> verterok: I fetch the file size from nodeAttr once I got the file with getContent(..)
[17:16] <verterok> karni: it should be in the FileInfoDelta, let me check the code
[17:17] <verterok> karni: the protocol code looks ok...are you sure that the file size != 0? :)
[17:18] <karni> verterok: Thank you for checking. Now let me brutally output that to stderr and make sure (SQL insert didn't complain, and it was indeed 0).
[17:19] <verterok> karni: brb, need to step out for a bit
[17:19] <karni> verterok: ok
[17:23] <karni> verterok: once you're back -- yes, it's all zeros (line 43 logs) http://paste.ubuntu.com/552521/
[17:23] <karni> aquarius: once we resolve that - yes, a simple sql query will provide a Volume size.
[17:28] <rye> hrw, the only thing that was missing was gnome-keyring daemon. org.freedesktop.secrets is provided by gnome-keyring and it is possible that it was not started
[17:28] <pazo`> rye: do you know ca. when the song will be ready? :)
[17:28] <karni> beuno-lunch: i'll be back in ~1h
[17:30] <hrw> rye: but ubuntuone-client does not depends on gnome-keyring so for non-gnome installations u1 is just purely broken?
[17:32] <rye> hrw, python-gnomekeyring is brought in by ubuntu-sso-client
[17:32] <hrw> rye: not here
[17:33] <hrw> 11:33 hrw@lucek:~$ apt-cache show ubuntu-sso-client|grep Depends
[17:33] <hrw> Depends: python (<< 2.8), python (>= 2.7), python-support (>= 0.90.0), python-dbus, python-gtk2, python-lazr.restfulclient, python-oauth, python-twisted-core, python-twisted-web, python-webkit, python-xdg
[17:33] <rye> hrw, you are using standard natty packages, right?
[17:34] <verterok> karni: weird, I'll try to debug that while I take a look to the connection/IOException handling
[17:34] <verterok> now, lunch!
[17:34] <hrw> rye: right
[17:34] <rye> hrw, there are nightlies ppa which contain the code that will be merged to natty/main later on which contains fixes and features that are not yet in main
[17:35] <karni> verterok: bon apetit! (you're awesome verterok )
[17:36] <hrw> rye: I used u1 just to sync gnote notes from desktop to n900 with conboy. now, when I moved to android it looks like there is no use for u1 for me anymore (I do not keep files there)
=== beuno-lunch is now known as beuno
[17:54] <pazo`> rye?
=== Franxesk is now known as Franxesk_afk
[18:43]  * CardinalFang listens to approaching thunderstorm and hastily appends "Acquire UPS" to his new-year's resolutions.
[18:44] <rye> pazo`, hi could you please re-check My DOwnloads page?
[18:46]  * karni is back
=== teknico_ is now known as teknico
[18:48] <karni> beuno: 17:50-18:00 we talked together with aquarius on what granurality should the sync have. could you have a look at that and let me know what you think? :)
[18:49] <beuno> karni, sure
[18:49] <beuno> let me convert that into my TZ and look it up
[18:50] <karni> bac: oh, sorry ^ ^ it's been about 1:50h ago
[18:51] <pazo`> rye: it worked! Thanks!
[18:52] <beuno> karni, right, I agree with aquarius
[18:52] <aquarius> beuno, aquarius is not sure what he thinks :)
[18:52] <beuno> syncing full volumes will make little sense on phones
[18:52]  * karni nods
[18:53] <aquarius> beuno, but if you know what you're doing, wouldn't it be great? Just create a folder called "Nexus S" and make it a UDF, and then drop things into it. Music, comic books, videos, photos, games, ringtones, books...
[18:53] <aquarius> beuno, that's pretty compelling, I think
[18:53] <beuno> aquarius, of course
[18:53] <aquarius> beuno, although I suppose the workaround is to create a "Nexus S" UDF, create a folder in it called "Everything", and then mark Everything as synced ;)
[18:54] <karni> aquarius: exactly
[18:54] <aquarius> this is why I wondered whether we can detect the size of a UDF/folder when someone favourites it, and warn "this will sync X GB to your phone" if it's more than a few hundred MB
[18:54] <beuno> aquarius, karni, does it have to be one or the other?
[18:54] <beuno> also
[18:54] <beuno> lets design for people who don't know what they're doing first
[18:54]  * aquarius laughs
[18:55] <karni> aquarius: yup, seems like a bug in the storage protocol java impl didn't let us do that. once that fixed, we're there.
[18:55] <aquarius> I still think that warning people about large syncs should be done even if just at folder level (not whole-volume level). And once we've got that warning at folder level, then there's no real reason to not offer whole-volume sync either, is there?
[18:55] <karni> beuno: not really, no. what I meant is
[18:55] <beuno> right, always warn
[18:56] <karni> beuno: implementing per-volume sync only is much more trivial then per-file sync
[18:56] <beuno> karni, then lets do it in that order
[18:56] <aquarius> no-one's suggesting *only* per-volume sync, are they? I think we should have all of per-volume, per-folder, and per-file
[18:57] <karni> aquarius: I was sensing what can we go for ;)
[18:57] <beuno> so we all agree
[18:57] <aquarius> I'd really like per-content-type as well, and per-search, and possibly per-time, but then again I'd like someone to invent a pie with no calories in it too :)
[18:57] <karni> beuno: we'll do it per-file and go up from there. per-file involves much delicate measures then per-volume.
[18:57] <karni> aquarius: hahah
[18:57] <beuno> aquarius, well, we're >< this close to being able to implement per-content thingies, since the low-level api to do that is done
[18:58] <karni> ok, so we've cleared that up.
[18:58] <aquarius> beuno, per-content-type for *any* content type? I didn't know that. Why didn't I know that?
[18:58]  * karni is a lil'bit lost right now
[18:58] <beuno> aquarius, yeah, we can filter by mimetype
[18:58] <beuno> karni, ignore this part of the conversation for now  :)
[18:58] <karni> hehehe
[18:59] <beuno> aquarius, we try to not tell you certain things, to keep you focused!  ;)
[18:59] <aquarius> cor. It's amazing the things you find out. I shall slap myself for not already knowing this :)
[18:59] <karni> bah, I'll use the moment and recall my other suggestion about auto-magic media content sync
[18:59] <beuno> aquarius, basically, this is how we do music scanning. Only look at files with certain mimetypes
[19:00] <aquarius> beuno, yeah, but I didn't think that API was exposed (even in the syncdaemon protocol)
[19:00] <beuno> aquarius, probably a days' work to expose it
[19:00] <karni> having scheduled content sync - we can use this time (or little bit more often) to check what media has been captured in the mean time
[19:00] <aquarius> oh, right, gotcha, I get it now.
[19:00] <beuno> it's in the DAL
[19:00] <karni> as media is timestamped
[19:00] <aquarius> beuno, right, good, then I did know about it. I was worried, there:)
[19:01] <karni> by doing so - the services doesn't have to run all the time, and we can adjust how often it should poll for new media content (i.e. new pictures/videos, etc)
[19:01] <karni> that's just a thought for CardinalFang, but we'll get there sooner or later.
[19:01] <beuno> karni, right, I think that's something between you and CardinalFang to figure out
[19:01] <aquarius> karni, by "poll", there, you mean "how often the Android service should start up and talk to the server to see what's new", yes?
[19:01] <karni> ok, so I'll use the (parentId, filename) trick to track favourite items
[19:02] <karni> aquarius: no no, we're talking about sync-ing up users pictures (not lying under /sdcard/u1/*),
[19:02] <karni> aquarius: this is what CardinalFang was working in the mean time
[19:03] <aquarius> karni, I thought there was a NewPicture intent or something like that?
[19:04] <CardinalFang> There may be.  I haven't seen it in testing yet.  It could be useful to catch a broadcast intent, as a way on ensuring code is running soon after a photo lands.
[19:04] <beuno> aquarius, karni's irc session died
[19:06] <karni__> aquarius: sorry, got disconnected
[19:07] <aquarius> CardinalFang, ah, OK. Catching a broadcast intent is obviously the best approach -- being event-driven is good for power, as you know :)
[19:07] <karni__> although it looks like i'm still around ;D
[19:07] <karni__> aquarius: right. however (sad news) I have verified what I wrote before, and it turns out
[19:07] <karni__> aquarius: MediaScanner was invoked on events such as boot and sd card mounted
[19:08] <karni__> aquarius: which means - the broadcast is not sent when a regular picture is taken (it's just saved directly to media content provider, instead of invoking the media scanner)
=== karni__ is now known as karni
[19:08] <aquarius> also...aren't pictures *always* saved to SD? Can't we just watch the folder, with some sort of inotify-ish thing?
[19:08] <aquarius> (er, saved to the filesystem, whatever that is)
[19:09] <CardinalFang> aquarius, yes.  This requires running code, though.
[19:09] <aquarius> CardinalFang, a good point and well argued. :)
[19:09] <karni> CardinalFang: or timed Alarm with a single sql query
[19:09] <karni> too bad I didn't see what Chad wrote :<
[19:10] <karni> ok, getting back to work
[19:10] <aquarius> and you can't receive intents if you're paused anyway, afaicr
[19:11] <karni> aquarius: you're talking about broadcast receivers? these can wake up the app.
[19:13] <aquarius> oh, you can if you statically register a broadcastReceiver in AndroidManifest. Good.
[19:13] <aquarius> not that it matters if there *is* no Intent for "just taken a picture". Damn.
[19:13] <karni> uhm :<
[19:19] <CardinalFang> Yeah, broadcast receivers are only hooked from what reads the AndroidManifest, I'm pretty sure.
[19:19] <aquarius> http://developer.android.com/reference/android/content/Intent.html#ACTION_CAMERA_BUTTON, although that might be only for a hardware camera button :)
[19:19] <CardinalFang> Yeah, that's how the camera app knows to begin running.
[19:19] <aquarius> oh, that's not the camera button to *take* a picture, it's the one to start the camera app? bah.
[19:20] <aquarius> my phone doesn't have a hardware camera button
[19:20] <CardinalFang> Well, it may do both.
[19:20] <CardinalFang> Mine either.
[19:21] <aquarius> be interesting to see if that intent is fired when taking a picture, though
[19:21] <karni> I'm 99.5% sure I've been there and checked that.
[19:21] <karni> I've really tried to find a broadcast action for what we needed.
[19:23]  * karni just had an Ubuntu 10.10 server failure, doh
[19:29] <CardinalFang> I've been thinking of making a Cron app or firmware hack.  It figures out some way of running all the time.  It broadasts intents for time.  You could register to hear  org.chad.Cron.MINUTE_20  to get run every hour.
[19:30] <aquarius> isn't this what AlarmManager is for?
[19:30] <CardinalFang> Dunno.
[19:30] <aquarius> http://developer.android.com/reference/android/app/AlarmManager.html
[19:30] <CardinalFang> These are not user-level events I have in mind.  Some service gets started.
[19:31] <CardinalFang> Ah.  Not bad.  Repeating, too.  Hmm!
[19:32] <CardinalFang> Okay.  Now I don't have to write that.  Yay!
[19:32] <aquarius> :)
[19:36] <karni> You guys head what I was saying ^ ^? Something sounding like... Alarm ;)
[19:37] <karni> Yes, that's exactly what I was talking about.
[19:37] <karni> We could see if there's new content in MediaProvider
[19:37] <karni> Since the last time we checked.
[19:37] <aquarius> yeah. If we can't be event-driven then we have to poll. Which sucks.
[19:38] <aquarius> would be worth pinging some android people and saying "there *must* be a way of doing this! surely! what is it?"
[19:38] <karni> aquarius: Still, this is relatively lightweight. Just one query using Alarms (which are adives way of doing repetitive work on Android)
[21:28]  * CardinalFang yells at bzr.
[21:52] <mpt> nessita, hi, https://wiki.ubuntu.com/NotificationDesignGuidelines may be relevant to the discussion I heard you having earlier
[21:52] <nessita> mpt: thanks! I'll take a look
[22:13] <beuno> CardinalFang, FWIW, song ids are md5s of the title+album+artist (IIRC)
[22:14] <beuno> er
[22:14] <beuno> CardinalFang, ignore that
[22:14] <CardinalFang> beuno, haha.  You're everywhere.
[22:14] <beuno> they are our own hashes from our DB
[22:14]  * beuno spies everything
[22:15] <beuno> CardinalFang, so, what I discussed with aquarius is that people need to make sure the files are in U1 anyway, so they may as well "verify" that by using our ID
[22:15] <CardinalFang> beuno, er, that's no good.
[22:15] <beuno> album ids are what we md5 to generate
[22:15] <beuno> CardinalFang, tell me more about this not good
[22:19] <CardinalFang> beuno, I think it's wrong to assume all the user's music files are going to be stored on Ubuntu One.
[22:19] <CardinalFang> beuno, would you like to rename this to be "ubuntuoneplaylists"?
[22:21] <beuno> CardinalFang, ah, that is probably the right thing to do
[22:22]  * CardinalFang notes that for tomorrow.
[22:22] <CardinalFang> G'night, all.
[22:22] <beuno> night CardinalFang