| === beuno_ is now known as beuno | ||
| dev85 | exit | 02:40 |
|---|---|---|
| dev85 | hello | 02:40 |
| === chihchun_afk is now known as chihchun | ||
| === chesedo- is now known as chesedo | ||
| === marcusto_ is now known as marcustomlinson | ||
| === chihchun is now known as chihchun_afk | ||
| aquarius | jhodapp, if I set a playlist playing from my app, and then my app gets killed, and I restart my app, how do I tell whether my playlist is still playnig? | 11:47 |
| davmor2 | aquarius: as I understand it if the app is closed the playlist is removed from mediahub completely I would assume that, that is the case for when an app is killed too but I could be wrong | 11:51 |
| aquarius | what? | 11:51 |
| aquarius | so how do I kick off a playlist which keeps playing in the background then? :( | 11:51 |
| aquarius | my app might get killed at any time as long as it's nor foreground. I thought the whole point of giving this stuff to the media hub rather than playing it myself was that it'd keep playing even if I got killed | 11:52 |
| davmor2 | aquarius: aiui as long as the app is open it will remain in the media-hub queue if oom kills it the app is still technically open so the playlist remains in place it has to be closed | 11:55 |
| davmor2 | aquarius: so no ticket in the spread anymore | 11:55 |
| davmor2 | aquarius: jim will be able to confirm | 11:56 |
| === _salem is now known as salem_ | ||
| jhodapp | aquarius, if your app is killed, then the playlist and everything associated with that player session is removed | 13:06 |
| aquarius | oh | 13:07 |
| aquarius | so, if I set a playlist playing, and then switch to another app, and Ubuntu kills my app, my app's music stops, and there is nothing I can ever do about that? | 13:07 |
| jhodapp | aquarius, correct | 13:07 |
| ogra_ | you could complain | 13:07 |
| jhodapp | lol | 13:07 |
| ahayzen | jhodapp, kills or OOM ? | 13:08 |
| aquarius | if I lock the phone, is the app that was in the foreground before I locked it guaranteed to not be killed? | 13:08 |
| ahayzen | jhodapp, i thought it would continue with OOM but only stop if that app was stopped by the user? | 13:08 |
| jhodapp | ahayzen, doesn't matter, if the app is no longer running in any way, it's player session is gone | 13:08 |
| aquarius | specifically: if I want to set music playing and then lock the phone, will Ubuntu sometimes stop that music playing even though I didn't tell it to? | 13:08 |
| ahayzen | jhodapp, so how are we going to stop music stopping when music loses its lifecycle exception ? | 13:08 |
| ogra_ | aquarius, only if something consumes your RAM ... which could make OOM kick in | 13:09 |
| jhodapp | aquarius, unless you run out of memory and the OOM killer kills your app, it should continue to play (assuming proper playback settings apply like repeat) | 13:09 |
| ahayzen | i would expect music to keep playing with OOM and only stop if music is *stopped* by the *user* | 13:09 |
| ogra_ | (which is surely a bug somewhere) | 13:09 |
| jhodapp | ahayzen, why? | 13:09 |
| ogra_ | ahayzen, "with OOM" ? | 13:09 |
| ogra_ | how would you do that .... magically make more RAM chips appear when you run out ? | 13:10 |
| aquarius | if the OOM killer kills the media hub, obviously music will stop -- nothing that can be done about that | 13:10 |
| ahayzen | because the user selects music to play, goes to the browser, loads websites...music is killed by the OOM killer thing... | 13:10 |
| ahayzen | i'd expect my music to keep playing | 13:10 |
| ahayzen | i don't care if the UI/app has been killed | 13:10 |
| popey | +1 | 13:10 |
| aquarius | if the OOM killer kills my app, I would *not* expect the music it's playing to stop | 13:10 |
| jhodapp | ahayzen, if music-app or whatever app playing your music is killed, that music playback will stop | 13:10 |
| ogra_ | ahayzen, so you would prefer that unity8 crashes but your music plays on ? | 13:10 |
| aquarius | that's the whole point of having the media hub in the first place! | 13:10 |
| ahayzen | ogra_, why would unity8 crash? | 13:10 |
| ogra_ | ahayzen, where would you take the ram from ? | 13:11 |
| ahayzen | ogra_, it is being played by media-hub not the music-app.. | 13:11 |
| aquarius | ogra_, absolutely I'd prefer that, yes. Why should my playing music be affected? | 13:11 |
| ahayzen | media-hub | 13:11 |
| popey | ogra_: you're misinterpreting | 13:11 |
| popey | he's not saying "Don't OOM" he is saying "if you OOM, don't stop music" | 13:11 |
| ogra_ | popey, huh ? | 13:11 |
| popey | (given the thing that was OOM-killed is _not_ the thing actually _playing_ the music" | 13:11 |
| popey | s/"/)/ | 13:11 |
| jhodapp | ahayzen, sure ideally, but that's not what the current implementation does...I'm not stating what a better design might or might not be | 13:11 |
| ogra_ | if you OOM, what plays the music ? | 13:11 |
| jhodapp | ahayzen, does Android do that? | 13:11 |
| ogra_ | OOM means there is no more free physical ram ... no way around that | 13:12 |
| ahayzen | ogra_, media-hub plays the music ... musicapp is just a UI for it | 13:12 |
| popey | ogra_: the media-hub has a playlist it was given | 13:12 |
| popey | ogra_: no, you're hung up on the ram thing - that's not the issue here | 13:12 |
| ogra_ | ah, so if you OOM *the UI* | 13:12 |
| ahayzen | so if music-app dies..media-hub has the list of tracks, shuffle, repeat etc...it doesn't *need* the music-app | 13:12 |
| popey | yes | 13:12 |
| ahayzen | Andriod keeps music playing when the app is OOM'd | 13:12 |
| ahayzen | or does for the Walkman app anyway | 13:12 |
| jhodapp | ahayzen, it may need it...it's a weird situation in that case IMO | 13:13 |
| aquarius | Consider this: I have an Ubuntu tablet at a party, and it's plugged into speakers and running the music for the party... and I have, on the screen, the cocktail menu for the party in a web page so people can look at it. I expect that Ubutnu will suspend or kill the music app because the music app is not the foreground app (the browser is). I do *not* expect that the music will stop, when that happens! | 13:13 |
| ahayzen | that's what i thought the major point of bgplaylists was with the other additional feature of the platform being able to control the queue | 13:13 |
| jhodapp | ahayzen, you no longer have full control over that session, and if it's set to play forever, how do you regain full control over it if you don't bring that app back up? | 13:13 |
| ahayzen | jhodapp, you select the app again in the spread..the music app is restored and session restored?! | 13:13 |
| ogra_ | jhodapp, your indicator controls should still have control | 13:14 |
| ahayzen | then you select pause | 13:14 |
| jhodapp | aquarius, playback will not stop in that case | 13:14 |
| jhodapp | ogra_, not full control, you can change repeat or shuffle or select a new track or album for instance | 13:14 |
| aquarius | jhodapp, er. You just said it would; if my app gets killed, it loses its session and its playlist stops. | 13:14 |
| jhodapp | *can't | 13:14 |
| ogra_ | jhodapp, but i can stop it | 13:14 |
| ogra_ | or pause | 13:14 |
| jhodapp | aquarius, the last situation you just mentioned did not say an OOM scenario | 13:14 |
| ogra_ | if i re-start the UI app it should recieve the playlist again from media-hub | 13:15 |
| jhodapp | ogra_, yes and we'd need some kind of method for identifying an existing session | 13:15 |
| ahayzen | ogra_, yeah exactly...the only time it should stop the music is if the *user* swipes up the music-app from the spread.. or they select pause | 13:15 |
| aquarius | so, apps are either (a) running (when foreground) (b) suspended (can happen at any time when you're not the foreground app) or (c) killed (which ONLY happens for OOM reasons)? | 13:16 |
| popey | (d) crashed | 13:16 |
| popey | (e) killed by user action | 13:16 |
| ahayzen | e) not running/stopped by user | 13:16 |
| ogra_ | d is a bug though | 13:17 |
| ogra_ | (not normal behaviour) | 13:17 |
| ahayzen | but the point is c != e | 13:17 |
| aquarius | but there's no way of me dealing with the transition between b and c -- if my app gets suspended because it's in the background, and then becomes the foreground app, my app's session comes back, but if my app gets OOM killed while it's in the background, and then becomes the foreground app, it'll lose its session. And, importantly, Ubuntu does not distinguish between these two things for the user | 13:17 |
| ahayzen | in the case of c) music should continue... it should only stop in e) | 13:17 |
| aquarius | the whole point of the lifecycle stuff is that your app might get killed but that's not supposed to matter, as long as the app dev is diligent about saving its state when it's backgrounded | 13:18 |
| aquarius | but you cannot save your media-hub session in your state! | 13:18 |
| jhodapp | the other thing is, how would I detect that an app was killed vs crashed vs normally quit? | 13:18 |
| ahayzen | aquarius, i sense you may need some of the info we are tracking here bug 1518160 | 13:18 |
| ubot5 | bug 1518160 in qtubuntu-media (Ubuntu RTM) "Once the music-app has a normal app lifecycle there needs to be a mechanism to sync the info lost during the suspend period" [Medium,Triaged] https://launchpad.net/bugs/1518160 | 13:18 |
| ahayzen | jhodapp, the StateSaver object only saves stuff when in OOM IIRC | 13:18 |
| aquarius | ahayzen, yeah, I see we're confronting the same issue! | 13:19 |
| ahayzen | jhodapp, https://developer.ubuntu.com/api/apps/qml/sdk-15.04.1/Ubuntu.Components.StateSaver/ .. so that knows somehow | 13:19 |
| aquarius | StateSaver only saves QML properties | 13:19 |
| jhodapp | ahayzen, right, this needs to be lower level | 13:19 |
| ahayzen | yeah but it knows the different between OOM and app closed | 13:19 |
| jhodapp | and anyway, it's a serious edge case | 13:19 |
| aquarius | if the media-hub made available a session-id or similar, then that could be StateSaver'ed | 13:19 |
| ahayzen | so can't the qtubuntu-media just use the same code ? | 13:20 |
| ahayzen | yeah or that aquarius | 13:20 |
| jhodapp | ahayzen, no idea, have never looked at statesaver | 13:20 |
| aquarius | of course if you try to resume a session by passing a session-id and that session has gone away, then it can't be resumed, but that's fine | 13:20 |
| ahayzen | yeah that seems like the best way | 13:20 |
| ahayzen | as there is already a session id internally with media-hub? right jhodapp ? | 13:21 |
| aquarius | but killing my playback just because Ubuntu killed my app seems daft, especially since the OOM killer kills background apps *all the time* and it's currently impossible to make things continue to work in that situation | 13:21 |
| jhodapp | ahayzen, yes absolutely, that's how each dbus communication identifies a particular player | 13:21 |
| jhodapp | aquarius, sure, but as I said before the real issue is why are you getting to an OOM situation...that should be a bug that should be fixed | 13:22 |
| jhodapp | so this should be a real edge case | 13:22 |
| aquarius | it isn't. | 13:22 |
| jhodapp | so that's a bug that needs fixing | 13:22 |
| ahayzen | you could be getting OOM'd for many reasons..many real reasons | 13:22 |
| ahayzen | i have N tabs open, email, games, music | 13:22 |
| jhodapp | doesn't happen on iOS | 13:22 |
| aquarius | Open music app: play a playlist. Open web browser; view web page. View web page 2. View web page 3. Music stops playing. | 13:22 |
| ahayzen | i'm sure it does | 13:22 |
| ahayzen | it happens on Android all the time | 13:22 |
| jhodapp | I'm not saying that it might not, but I've never noticed an app get killed | 13:23 |
| ahayzen | 'noticed' | 13:23 |
| ahayzen | it probably has in the background | 13:23 |
| jhodapp | possibly | 13:23 |
| popey | jhodapp: easy to test - open two apps :) | 13:23 |
| aquarius | jhodapp, really? Try uploading a file to a web page. Half the time, the web page itself gets killed while you're in the Content Hub choosing the file to upload :( | 13:23 |
| popey | (also, happens way more on bq e4.5 than mx4) | 13:23 |
| ahayzen | remember apps don't take 5 seconds to start on iOS ;-) | 13:23 |
| popey | meow | 13:23 |
| ahayzen | hehe | 13:24 |
| jhodapp | aquarius, you're misunderstanding me, I'm not saying that it doesn't happen on Touch but it should not happen so easily and that is the real bug to fix first | 13:24 |
| * popey downloads more ram | 13:24 | |
| ahayzen | but the real point is this is still a use case and will be forever until someone creates infinite RAM or cloud RAM or something :') | 13:25 |
| aquarius | jhodapp, that's the real bug to fix. It isn't the real bug to fix first, because it's completely open-ended, it'll never be entirely fixed, and everyone is screwed *until* it's fixed. If we make it so app devs can Do The Right Thing *even while the OOM killer is really aggressive*, then we can deal with the problem | 13:25 |
| jhodapp | aquarius, sure, I'm not opposed to it however there's many things to implement on our end and we're very short staffed | 13:25 |
| jhodapp | aquarius, I'd be happy to help you get started in implementing this | 13:25 |
| aquarius | so, we'd need media-hub to not decide to kill a session just because its app goes away, and to provide some way of an app "reconnecting" to that session if the app has the session ID | 13:27 |
| ahayzen | surely somewhere in mir/qtmir/somewhere it knows if the app has been OOM killed/closed ? | 13:27 |
| ahayzen | as keeping *all* the sessions around just in case an app uses the same ID doesn't feel too efficient | 13:28 |
| aquarius | security problem there, perhaps, unless it's possible to tell that "this app talking to me now is the same app that was talking to me before, even if it's got a different D-Bus endpoint because it was killed and restarted" | 13:28 |
| jhodapp | aquarius, yes, so you'd need some way of an identifying and app to a player session and getting that back to media-hub when it tries to restore a session | 13:28 |
| aquarius | ahayzen, you only need to keep the session ID around for *the currently playing music* | 13:28 |
| ahayzen | ah yeah..i guess | 13:28 |
| ahayzen | currently playing on the multimedia role :-) | 13:28 |
| jhodapp | aquarius, yes indeed, this is not a simple thing...I've thought through it a bit before and we'd want a proper architecture and security review | 13:29 |
| aquarius | I am perfectly fine if this happens: start music app, tell it to play playlist, OOM kill music app, (music keeps playing), start game, game plays music (stopping the playlist), restart music app, music app tries to resume session, media hub says "no such session". | 13:29 |
| ahayzen | just take the APP id + session id as the identifier | 13:29 |
| aquarius | that's fine -- the music got stopped explicitly by the user | 13:29 |
| ahayzen | aquarius, yeah that makes sense | 13:29 |
| aquarius | if there is such a thing as an "app id" on D-Bus, then that'd work, ahayzen | 13:30 |
| jhodapp | aquarius, he means the apparmor app id, right ahayzen? | 13:31 |
| ahayzen | media-hub knows it is com.ubuntu.music playig? thought ? | 13:31 |
| ahayzen | *i thought | 13:31 |
| jhodapp | yes | 13:31 |
| ahayzen | so use that + session id | 13:31 |
| jhodapp | that would probably work | 13:31 |
| aquarius | ya, but you don't want a newly installed different app to be able to use that ID, and there's no way to prevent that, is there? | 13:31 |
| ahayzen | that (sil.music-app, 1) != (com.ubuntu.music, 1) | 13:31 |
| ahayzen | *then ...(i can't type today) | 13:31 |
| jhodapp | aquarius, that's enforced via the click package | 13:31 |
| aquarius | we don;t actually even need a session ID, then, do we? Since there's only one active session. So just use the app ID *as* the session ID? | 13:31 |
| aquarius | music app just keeps the app ID that started this session around. | 13:32 |
| ahayzen | aquarius, but do we want a way to say yes restore or no we want a new session | 13:32 |
| aquarius | ahayzen, ya, you'd want a resume: True property on Audio | 13:32 |
| aquarius | and if you *wanted* to start a new one, you'd set resume:False | 13:33 |
| ahayzen | hmmm is that on MediaPlayer? | 13:33 |
| jhodapp | ahayzen, you could have a flag on the new session dbus method | 13:33 |
| aquarius | (or maybe it's a resumeSession() method on MediaPlayer and Audio, whichever) | 13:33 |
| ahayzen | yeah anything like that could work | 13:33 |
| ahayzen | and in that same session could the method return the info for bug 1518160 ;-) | 13:34 |
| ubot5 | bug 1518160 in qtubuntu-media (Ubuntu RTM) "Once the music-app has a normal app lifecycle there needs to be a mechanism to sync the info lost during the suspend period" [Medium,Triaged] https://launchpad.net/bugs/1518160 | 13:34 |
| jhodapp | aquarius, so we do have detach_session and reattach_session methods in media-hub today | 13:35 |
| ahayzen | so resumeSession() then returns {"played": [1,2,3,4]} or something | 13:35 |
| jhodapp | aquarius, they need debugging however as things don't resume perfectly | 13:35 |
| aquarius | ahayzen, those would be properties on the QML object(s) rather than returned from a method, but yeah | 13:35 |
| ahayzen | :-) | 13:36 |
| aquarius | jhodapp, sounds like most of this is already done from an architecture point of view; it just needs the dots to be connected? | 13:36 |
| aquarius | that's pretty cool | 13:36 |
| jhodapp | aquarius, and these methods take the app id and a unique session id into account | 13:36 |
| jhodapp | aquarius, yes indeed | 13:36 |
| ahayzen | sweet :-) | 13:36 |
| aquarius | jhodapp, is the unique session ID actually needed? | 13:36 |
| ahayzen | are you allowed two MediaPlayer objects in the same app ? | 13:37 |
| ahayzen | or two Audio{} ? | 13:37 |
| aquarius | huh | 13:37 |
| jhodapp | aquarius, I don't remember...I didn't write this code (ricmm did) and it's been a long while since I've looked at it | 13:37 |
| ahayzen | what happens if i want two audio sounds playing | 13:37 |
| aquarius | I figured they'd be part of one session | 13:37 |
| aquarius | because you can't play two sounds simultaneously | 13:37 |
| aquarius | you can play two SoundEffects, but not two Audios | 13:37 |
| ahayzen | ah cool | 13:37 |
| aquarius | but maybe I'm wrong about that | 13:37 |
| jhodapp | aquarius, you can play two sounds simultaneously, depends on your audio role | 13:37 |
| aquarius | (or maybe you can't but you *should* be able to :)) | 13:37 |
| ahayzen | for multimedia, maybe you shouldn't | 13:38 |
| jhodapp | you can't for multimedia | 13:38 |
| jhodapp | that's always true | 13:38 |
| ahayzen | but you can see a case for games or alerts | 13:38 |
| jhodapp | absolutely | 13:38 |
| aquarius | *nod* multimedia is what we're thinking of here | 13:38 |
| aquarius | sure, but alerts are the alert role; those don't have a session because they're fire-and-forget | 13:38 |
| jhodapp | aquarius, let me point you to the code I'm referring to, one min | 13:38 |
| aquarius | jhodapp, completely separate question: when playnig back an ogg vorbis file on Bq E4.5 it's stopping playback/dropping out for a short time every few seconds. What do I need to look at to work out why? | 13:39 |
| jhodapp | aquarius, here you are: http://bazaar.launchpad.net/~phablet-team/media-hub/trunk/view/head:/src/core/media/service_skeleton.cpp#L121 | 13:40 |
| aquarius | I'm not likely to be able to help much with C++ stuff; I'm not clever enough :) | 13:40 |
| ahayzen | :-) | 13:40 |
| jhodapp | aquarius, is this over the normal phone speaker? | 13:40 |
| aquarius | yup, normal phone speaker | 13:40 |
| * ahayzen has Uni work todo..but later in the year if this is still a problem..maybe i'll take a look ;-) | 13:41 | |
| jhodapp | aquarius, I'd be curious what the system load looks like during this as well as the specific CPU usage of media-hub-server | 13:41 |
| aquarius | might be worth linking to this conversation from the bug, ahayzen? | 13:41 |
| ahayzen | yeah, into bug 1518160 ? or a separate one? | 13:41 |
| ubot5 | bug 1518160 in qtubuntu-media (Ubuntu RTM) "Once the music-app has a normal app lifecycle there needs to be a mechanism to sync the info lost during the suspend period" [Medium,Triaged] https://launchpad.net/bugs/1518160 | 13:41 |
| aquarius | jhodapp, what's the best way to get that data? top? | 13:41 |
| jhodapp | aquarius, yes or even slightly better, install htop | 13:42 |
| jhodapp | ahayzen, let's change that bug description to be more specific, something like: "If music-app is killed by the OOM handler while playing music, it's player session should continue to live on" | 13:43 |
| ahayzen | jhodapp, ok, i've added a comment with the IRC log | 13:44 |
| ahayzen | updated bug 1518160 :-) | 13:44 |
| ubot5 | bug 1518160 in qtubuntu-media (Ubuntu RTM) "If music-app is killed by the OOM handler while playing music, it's player session should continue to live on and info lost during the suspend period needs to be exposed" [Medium,Triaged] https://launchpad.net/bugs/1518160 | 13:44 |
| jhodapp | ahayzen, thanks man | 13:44 |
| aquarius | jhodapp, while playing (and getting the minor dropouts), media-hub CPU is at 6.3%. Pulseaudio is at 11%. The dropouts are fairly regular (that is, they happen every 4-5 seconds) | 13:55 |
| ahayzen_ | aquarius, have you tried different ogg files ? | 14:01 |
| aquarius | I have | 14:01 |
| ahayzen_ | maybe it is how that one is encoded | 14:01 |
| aquarius | I thought of that :) | 14:01 |
| ahayzen_ | we have had weird stuff happen with different encodings | 14:01 |
| aquarius | might be an encoding thing, I suppose | 14:01 |
| aquarius | I'll have a fiddle with my avconv line :) | 14:01 |
| ahayzen_ | not sure if turning the debug on media-hub/gst would help ? | 14:02 |
| jhodapp | aquarius, out of curiosity, does it drop out on an Ubuntu desktop using a client that uses gstreamer? | 14:02 |
| jhodapp | ahayzen_, possibly | 14:02 |
| aquarius | it does not drop out on an Ubutnu desktop in totem | 14:03 |
| jhodapp | aquarius, try this: "stop media-hub; GST_DEBUG=*:3 CORE_UBUNTU_MEDIA_SERVICE_VIDEO_SINK_NAME=mirsink CORE_UBUNTU_MEDIA_SERVICE_AUDIO_SINK_NAME=pulsesink media-hub-server" | 14:03 |
| jhodapp | aquarius, make sure to quit and restart music-app | 14:03 |
| aquarius | doing that now | 14:03 |
| aquarius | (it's not actually music-app, it's my app, but I'm restarting it as expected, and we'll see what happens) | 14:04 |
| jhodapp | yup | 14:04 |
| aquarius | 0:01:06.740346927 5065 0xff1d80 WARN pulse pulsesink.c:702:gst_pulsering_stream_underflow_cb:<audio-sink> Got underflow | 14:04 |
| aquarius | that seems to be thrown when there's a dropout | 14:05 |
| jhodapp | aquarius, seems like a bad encoding | 14:05 |
| aquarius | cool. I will do different encodings until I find one that works then! | 14:05 |
| jhodapp | aquarius, or the ogg decoder in gstreamer isn't that great | 14:05 |
| aquarius | it also writes a shedload of: | 14:05 |
| aquarius | 0:01:36.421771083 5065 0xfc0280 FIXME bin gstbin.c:4075:gst_bin_query: implement duration caching in GstBin again | 14:05 |
| aquarius | i am happy to use some other format | 14:05 |
| jhodapp | aquarius, yeah I see that in a lot of different decoding scenarios | 14:06 |
| aquarius | I was worried that some phones might not have mp3 support out of the box? | 14:06 |
| aquarius | hence choosing vorbis | 14:06 |
| aquarius | but if there's some better idea, I'm happy to change | 14:06 |
| jhodapp | aquarius, they will all have mp3 support out of the box | 14:06 |
| ahayzen_ | is mp3 in the /ubuntu image? or only in the device ones with their extra binaries ? | 14:06 |
| aquarius | even third party ports? | 14:06 |
| ahayzen_ | i thought the /ubuntu images were 'pure' OSS | 14:07 |
| jhodapp | aquarius, not sure about the 3rd party ports | 14:07 |
| aquarius | hence not wanting to use mp3 ;) | 14:07 |
| aquarius | I'll fiddle with the avconv vorbis parameters | 14:07 |
| * ahayzen_ adds FLAC to the argument ;-) | 14:07 | |
| jhodapp | aquarius, investigate that though just to make sure | 14:07 |
| aquarius | yay, encoded with oggenc rather than avconv and changed the quality and now no dropouts. Thank you jhodapp | 14:21 |
| jhodapp | aquarius, awesome, np | 14:21 |
| ogra_ | kool kids use flac anyway :P | 14:21 |
| ahayzen_ | \o/ | 14:21 |
| aquarius | I don't need lossless for this :) | 14:22 |
| ogra_ | hwo else do you fill your externnal SD then o_O ? | 14:22 |
| jhodapp | or stay warm with your portable heater phone ;) | 14:22 |
| === ahayzen_ is now known as ahayzen | ||
| === chihchun_afk is now known as chihchun | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === chihchun is now known as chihchun_afk | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === JanC_ is now known as JanC | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!