**** BEGIN LOGGING AT Wed Nov 25 03:00:55 2015 Nov 25 04:14:32 morning Nov 25 04:14:42 Just my 5:15 checking LOL :P Nov 25 04:15:25 -g :P Nov 25 04:17:25 Garfonso: You awake yet LOL ? Nov 25 05:17:35 Dood moring Herrie my 12:00am bed time check out :) Nov 25 05:19:39 s/d/g Just to let you know that when you get appmenu working that the calander app ahs a menu that it broke i know i point it to the wrong kind and needs fixing Nov 25 05:20:30 morning Nov 25 05:21:09 Herrie: no, today she was active around 2 o'clock and then slept straight till 6 o'clock. Very kind of her. :) Nov 25 05:28:17 Cobblemonster: OK good to know Nov 25 05:28:29 Garfonso: LOL someone here is on a 4:30 schedule :S Nov 25 05:28:49 Didn't help I wasn't in bed before 1:30 :S I guess I need a lot of strong coffee today :P Nov 25 05:29:50 Ach, the wee bairns. What would we do without them? Nov 25 05:30:03 Sleep more soundly, for one. Nov 25 05:30:45 DougReeder: My wife's FitBit told me i have a 94-95% sleep efficiency ;) SO I cannot complain ;) I guess that's why I can function well on 5 hrs :P Nov 25 05:31:12 Ooo, that would be nice. I need 8 hours. Nov 25 05:33:04 I like > 5 hrs but can do perfectly fine on it ;) Mrs used to have around 65% while breastfeeding at night :P Nov 25 05:38:54 Tofe: I've already seen a few times that I get a boot loop Nov 25 05:39:03 Even before your fix Nov 25 05:39:07 You want a log? Nov 25 05:39:37 DougReeder: Tofe found the cause for the App Menu not working on the noWindow apps. Will test it shortly Nov 25 05:39:44 Might also solve the relaunhc issue Nov 25 05:39:53 Yay! Nov 25 05:54:26 I need 8 hrs at least, too.. so I'm a bit slow right now. ;) Nov 25 06:23:47 ka6sox: ping Nov 25 06:33:03 Herrie: a boot loop ? arg! Yes, if you have the log, I'm all in. Nov 25 06:34:08 Herrie: my fix is for all PalmSystem.isActivated related issues, but the only known so far is only the appmenu bug Nov 25 06:35:15 Tofe: Yeah, if I do a relaunch to clock app when it's not focused, it will focus it but not open the app menu yet Nov 25 06:35:33 Tofe: I think the boot loop is due to the legacy apps I loaded onto device but not sure Nov 25 06:35:37 Let me email you some logs Nov 25 06:37:20 Tofe: That's relaunch to get the app menu Nov 25 06:37:34 If the clock app is focused and I send the same luna-send it will show teh app menu Nov 25 06:37:40 But at least it shows an app menu now Nov 25 06:37:42 In email too Nov 25 06:38:03 You should check email on VBOX emulator, I have some overlay issues there obviously. Nov 25 06:38:09 It's also on N4 but less noticable Nov 25 06:54:15 Gosh that latest xkcd is a trap, I need to go to work! Nov 25 08:00:14 * elvispre reads yesterday's log and realises that Tofe and Herrie were discussing clock already. I thought they seemed well-informed. Nov 25 08:13:37 re-morning Nov 25 08:21:32 Herrie: for the redirect handling, I say we wait until Qt 5.6: http://doc-snapshots.qt.io/qt5-5.6/qwebengineurlrequestinterceptor.html Nov 25 08:52:02 Tofe: depends if it's an easy backport I guess it would be better to have now, but I guess it isn't right? Nov 25 09:07:41 That one doesn't seem very easy; and maybe not worth it, as we will get Qt 5.6 probably in a month or so Nov 25 09:22:17 Tofe: Yeah let's focus on getting some other stuff ironed out first ;) Nov 25 10:11:35 elvispre: We were mainly focussing on the app menu issue. That is now more or less sorted. It works now for noWindow apps :) Nov 25 10:11:40 Which is didn't before Nov 25 10:12:02 s/is/it Nov 25 10:12:59 Herrie: Hi, yeah I saw that. I have been wondering what's wrong with alarm control in the clock. Nov 25 10:13:28 Herrie: As I mentioned yesterday, what's wrong is that the code is nonsense. Nov 25 10:13:45 Herrie: I'll try to fix that when I am back at home later in the week. Nov 25 10:14:06 elvispre: Great Nov 25 10:14:16 Yeah I saw it doing double alarms or no alarms and stuffs Nov 25 10:15:08 Herrie: The QtWebEngine change seems to have fixed the double alarms issue. Nov 25 11:30:08 elvispre: At least some good things come from the migration ;) Nov 25 11:30:27 I.e. a long overdue proper review of functionality and fixing of bugs ;) Nov 25 14:11:58 Andolamin: Ping Nov 25 14:24:25 Pong Nov 25 14:24:51 Herrie: What's up? Nov 25 14:43:00 Andolamin: Since your RPi is a bit different compared to our usual targets, I wondered if you experienced the UI freezing after x amount of time. Nov 25 14:43:37 I.e. we can shell into device, but screen doesn't come back on. I have seen this on all targets so far, just not sure if it also appears on Rpi Nov 25 14:44:49 Yep, it's on the RPi, too. Nov 25 14:45:09 Ok then it's probably something in lunasysmgr or dbus Nov 25 14:45:13 We already suspected that Nov 25 14:45:31 More evidence never hurts Nov 25 14:57:19 Herrie: OTOH - It may not actually be occurring on the RPi, instead something similar. The RPi screen can't turn off, so when I saw it I just suspected that luna-next-cardshell was going into sleep mode and since I couldn't trigger the wake to show the lockscreen it was just freezing up instead. Plausible? Nov 25 14:59:15 Andolamin: We sometimes have it with screen on, sometimes with off Nov 25 14:59:23 It just locks, but can still shell into it Nov 25 14:59:43 Before that UI usually slows down significantly so could be some memory leak somewhere Nov 25 15:01:07 Could be. I'll take a look at it over the holiday weekend, see if I can figure anything out. Nov 25 15:02:53 DougReeder: ping Nov 25 17:08:28 morphis: YOu remember if you got any clues with regards to above? Nov 25 17:08:35 I remember you were looking into it Nov 25 20:22:56 Andolamin, pong. Nov 25 20:24:16 DougReeder: https://github.com/Andolamin/com.alanstice.cast/wiki/API Nov 25 20:24:37 Niffty! Nov 25 20:25:46 Got any sample scenarios that show the order of calls? Nov 25 20:27:45 canCast should probably return a returnValue of true, to assert the service exists. Nov 25 20:27:58 returnValue would be false if the service wasn’t installed. Nov 25 20:28:49 Not yet. I'll have a sampler app in that repo, along with a configuration app (like Google's Chromecast app for Android) and the service itself. Most of those calls will probably only be used internally, as I'm thinking I'll show a dashboard with playback controls while casting. Nov 25 20:28:57 returnValue could be false if the subscribe flag wasn’t set. Nov 25 20:28:59 Good catch, they should all have returnValue Nov 25 20:30:45 canCast may be redundant with listDevices. Nov 25 20:30:50 Oh, I see what you're saying. returnValue is there, but I have it always returning false. I need to add errorCode and errorText there. What I usually do in that case is {"returnValue": false, "errorCode": -1, "errorText": "Request must be a subscription"} Nov 25 20:31:49 Yes, the same capability can be done with listDevices, but for just a visible flag, this is lighter weight and maps more directly. Might be preferable? Nov 25 20:32:45 Originally I didn't have canCast, then added it recently. Not hard to convince me to remove it. Nov 25 20:33:38 IIRC, returnValue is the only member that has to be set. You should always set errorCode if returnValue is false. errorText is very useful for debugging. Nov 25 20:35:59 THere’s several errorCode values you shouldn’t use (such as -1), because the PalmBus uses them. See http://www.webos-internals.org/wiki/JavaScript_Services Nov 25 20:37:07 I know, it was just an example Nov 25 20:37:39 I reccomend using uppercase, snake-case strings for errorCodes. Some internal services do, and theyre much more clear. Nov 25 20:39:45 I can’t imagine more than a handful of devices being available at any given time, so the payload fro listDevices shouldn’t be too large. Nov 25 20:40:56 Yeah, I'll just remove canCast Nov 25 20:41:03 Less to maintain Nov 25 20:41:51 How would media/getDuration be used? Nov 25 20:43:24 If you don't know the duration of the media before sending it to the target, it can give you the information for seek bars. Subscribing it useful because that value can change for streams or during with video/audio playlists. Nov 25 20:44:05 Not something that a third party app would probably use, as it would probably just be used for the playback dashboard. Nov 25 20:44:27 I guess the casting app could use it to show a now playing UI, like android apps tend to do with chromecast. Nov 25 20:49:04 Would a playlist be a single Media object, or an array of them? Nov 25 20:50:05 Depends. If you already have a playlist generated you would send that as a single object. If you don't have one generated send an array of Media objects and the service would generate the playlist first. Nov 25 20:51:31 So, the playlist/* commands presume the target device has a playlist? Nov 25 20:53:54 Right, the service would throw an error and returnValue: false if there's no playlist going Nov 25 20:56:01 So, you might send a playlist, have the TV start working through it, have another device send a different playlist, then the first device sends playlist/jumpTo, the TV jumps to whatever had that index in the other playlist? Nov 25 20:59:27 If you call playMedia with a list of some local and some remote items, what would the local flag be? Nov 25 21:04:00 local would be true for each local item, false for each remote item. Meant to remove the top-level local flag Nov 25 21:04:28 Yeah, the top-level flag is problematic. Nov 25 21:05:17 It's gone now :) Nov 25 21:05:31 Is position in seconds? Nov 25 21:05:51 Yeah Nov 25 21:06:06 You should probably note that. Nov 25 21:06:30 Just did. I had on the getPosition call, but not on seek Nov 25 21:09:25 So, in my two-casting-devices scenario, a device could subscribe to media/getStatus, and if playingMedia didn’t match what was expected, it would know the TV was on someone else’s playlist? Nov 25 21:10:49 Multi-device scenarios will be a rich source of unexpected situations. :-) Nov 25 21:12:38 Ah, and you’ll want to consider when the service should stop running. Nov 25 21:12:50 Yeah, it would lead to many unexpected problems. The goal would be to limit control to the original device as much as possible. Nov 25 21:13:43 For Zap, the app pings the service to keep it alive. When the user doesn’t want to share anymore, tossing the card away stops sharing. Nov 25 21:13:44 Regarding stopping running, I plan to make it dynamic. So as long as it's not actively casting something, and there are no active subscriptions, it would close out. Nov 25 21:14:09 So the app wouldn’t need to keep running? Hmm Nov 25 21:14:50 What does “actively casting” mean in this context? Nov 25 21:15:46 Well, for webOS TVs, as an example, casting something to the TV requires an open websocket connection to the TV, so that open websocket connection would keep the service running Nov 25 21:15:53 Similar for Chromecast Nov 25 21:17:04 An option could be to force subscribing when you call playMedia, because then if the user throws that app away the cast service could catch the cancel event and stop the cast. Nov 25 21:17:46 But, I liked the idea of the dashboard for controlling the currently casting media. No need to keep the original app open, you can just control and stop the casting from the dashboard. Nov 25 21:18:41 That’s a good idea. The user could close the dashboard to stop casting. Nov 25 21:19:22 Exactly Nov 25 21:19:51 Subscribing to playMedia isn’t documented to return any useful info. Nov 25 21:19:54 Also, you could get something casting and switch to another app, but then control the cast without having to switch back to the original app Nov 25 21:20:04 * DougReeder nods Nov 25 21:21:28 You might have the subscription responses to playMedia return the same info as media/getStatus. Nov 25 21:21:30 Not finished with that yet, probably would use that to indicate informational events (connected, player opened, media sent) and disconnection events Nov 25 21:21:55 Good idea Nov 25 21:23:50 With all the subscriptions, you should probably think about what happens when you start another playlist. Might be useful for old subscriptions to end. Nov 25 21:24:06 Or maybe the subscription ends when the associated event is done. Nov 25 21:27:07 Hmm. Yeah. I guess it would depend on if the new playMedia came from the same app or a different app. If same app, the old subscriptions could be reused. If new app, they should be cancelled. But that would make the call behavior complicated to handle. Maybe just end them all when the new call happens... Nov 25 21:29:00 It’s probably best for a subscription to end when the associated activity ends. So, open dashboard when playMedia succeeds, close it when the subscription ends. Nov 25 21:34:28 Subscriptions to media/getPosition and getDuration should … do what when a playlist advances to the next item. Nov 25 21:35:06 Is getDuration for the whole playlist or the current media? Nov 25 21:35:15 Likewise getPosition? Nov 25 21:36:03 As long as the subscription is running, it should be whatever is playing. So it would carry through playlist items. Nov 25 21:37:00 so, duration and position would jump when the playlist advance to the next item? Nov 25 21:37:14 Yeah Nov 25 21:37:42 I guess that’s usual for media players. Nov 25 21:38:27 Works well when the playlist is some kind of album, poorly when a playlist is chunks of the same thing. Nov 25 21:41:38 To tell when a playlist has advanced to the next item, check the playingMedia field of a media/getStatus subscription? Nov 25 21:42:33 Yeah Nov 25 21:43:22 Do getPosition and getDuration really need to be separate from getStatus? Nov 25 21:44:41 Not really. They are on the target side, but that could be abstracted out by the service. Would probably add a changed array to the response so it would only have to include the values that triggered the update, though. Nov 25 21:45:37 I can see arguments both ways. Nov 25 21:46:24 As an app developer, I can see updating UI for all three when any update occurred. Nov 25 21:47:55 Gotta go; I’ll look it over more tonight. Nov 25 21:48:16 Thanks! **** ENDING LOGGING AT Thu Nov 26 03:00:38 2015