| *** frinring_ is now known as frinring | 00:33 | |
| *** zbenjamin is now known as Guest11966 | 01:12 | |
| *** zbenjamin_ is now known as zbenjamin | 01:12 | |
| *** frinring_ is now known as frinring | 01:41 | |
| dcaliste | Hello chriadam, how are you ? | 07:02 |
|---|---|---|
| chriadam | hi dcaliste, I'm well thank you - how was your vacation? | 07:03 |
| dcaliste | Great, great, visited my parents in law in Vietnam. | 07:03 |
| chriadam | nice one :-) | 07:04 |
| dcaliste | Let summarize pending MRs, starting with mkcal: | 07:05 |
| chriadam | sounds good | 07:05 |
| dcaliste | - https://git.merproject.org/mer-core/mkcal/merge_requests/24 -> should solve the issue of exception of all days stored in another timezone. | 07:05 |
| dcaliste | flypig mentioned that the all day detection is weird, which I agree with, but should match the current state else where in the file | 07:07 |
| dcaliste | pvuorela reviewed the MR also and mentioned if we should correct it in nemo-qml-plugin-calendar when dealing with expandedRewEvents() | 07:09 |
| dcaliste | This is the best solution, but when looking to the KF5 transition in the future, rawExpandedEvents() should stay with QDateTime and not KDateTime, which means that it will always have a tz, if not the system one. | 07:10 |
| dcaliste | So in my opinion, there is no way future compatible to make expandRawEvents() to return date time in clock time, so recurrence ids cannot be in clock time (because recurrence ids are taken as the date time returned by expandRawEvents). | 07:11 |
| chriadam | urgh | 07:12 |
| dcaliste | The best way, in my opinion is to apply the current patch which has the drawback to make impossible to store all day events in a given time zone. | 07:12 |
| chriadam | what does that drawback imply? | 07:13 |
| dcaliste | Which means that Bastille day in France cannot be seen as starting at 5 am in Vietnam ;) | 07:13 |
| chriadam | I see. | 07:13 |
| dcaliste | It will start also at 00am the 14th July even in Saigon… | 07:13 |
| dcaliste | To make it so, one needs to save it as a none all day event, but one that starts at 0am and finishes at 23:59. | 07:14 |
| chriadam | that seems fine to me. for timezone-specific all-day events, maybe it should be saved as a 23 hour, 59 minute, tz-specific, non-all-day event... to ensure specific | 07:14 |
| chriadam | indeed | 07:14 |
| chriadam | not so bad from my perspective (although we don't have such support in the UI yet) | 07:14 |
| dcaliste | I agree. Also, looking at how upstream kcalcore is treating all day events parsed from iCal data is interesting (since KDateTime::isDayOnly() does not exist any more and there is no clock time spec time): | 07:16 |
| dcaliste | they save the date time as a QDateTime (with QTime = 00:00, but we don't really care), and use the allDay() flag from the event, no spurious detection of clock time and QTime == 00:00. | 07:17 |
| dcaliste | I was doing review in mkcal to see if we could adopt this strategy already now, and still being backward compatible. | 07:18 |
| dcaliste | This leads us to https://git.merproject.org/mer-core/mkcal/merge_requests/17 | 07:18 |
| dcaliste | I will revamp it following such consideration of using allDay() attribute only. | 07:20 |
| chriadam | right, I see that Pekka had a comment there | 07:20 |
| dcaliste | I need to check also the md pad from flypig to see if this approach can be compatible with Thunderbird at least. | 07:21 |
| dcaliste | If I find time, I would like to test it with Gnome-calendar also. | 07:21 |
| dcaliste | So, I'm going to add a WIP tag to MR!17 for the time being, if you agree. | 07:23 |
| chriadam | sure | 07:24 |
| chriadam | honestly, until Pekka gets back from vacation I'm not sure there will be too much movement on those anyway, as we're spread pretty thin at the moment | 07:24 |
| dcaliste | - https://git.merproject.org/mer-core/mkcal/merge_requests/25 a new one, coming from vacation brainstorming… | 07:26 |
| dcaliste | No problem for the time schedule, mainly discussing current state ! | 07:27 |
| dcaliste | After much thinking, the MR!25 is a one liner that should correct the last modified behaviour that makes the addition of etag and urls in caldav plugin such a mess. | 07:28 |
| dcaliste | I think that it should have no drawback, at least I cannot see any after much thinking about it, but I agree that it's a sensitive matter ! | 07:28 |
| dcaliste | If accepted, it means that we can change the last modified date by hand if required, so we can set it back to previous value when adding etag and urls. | 07:29 |
| chriadam | I agree, but it definitely needs thought and testing | 07:33 |
| dcaliste | Of course. I agree also to put a comment, but maybe one explaining that the lastModified field is not a field to manage the databse status itself, but a user-defined field from iCal RFC, so it should be possible to change it by hand. | 07:35 |
| chriadam | yes | 07:36 |
| chriadam | makes sense | 07:36 |
| dcaliste | I've tested it quickly in jolla-calendar, and modification dates are indeed properly updated on UI changes. | 07:36 |
| chriadam | cool | 07:37 |
| dcaliste | Thanks to the ExtendedCalendar::incidenceUpdated() callback. | 07:37 |
| chriadam | (every time I look into mkcal I wish we had implemented a native qtorganizer backend. c'est la vie) | 07:37 |
| dcaliste | But further testing will be safer, indeed. | 07:37 |
| dcaliste | Yep, but doing it now is really to complicated in my opinion, since it's the mkCal API that is used everywhere, not so much the Core one. | 07:38 |
| dcaliste | Besides, I'm trying to decrease calling mkCal API whenever I can and use Core one whenever possible: I've a MR in CalDAV doing it for instance with addition and update of incidence. | 07:39 |
| dcaliste | I've seen that upstream KCalCore also have the dissocateSingleOccurrence() API now, so maybe one day we can make the mkCal API almost completely private… Then we will be able to switch backend… | 07:40 |
| chriadam | indeed :-) | 07:40 |
| dcaliste | Far future though ! | 07:41 |
| chriadam | indeed | 07:42 |
| chriadam | dreams of green grass may have to wait ;-) | 07:43 |
| chriadam | was there another caldav PR aside from the server-calendar-detection one? I thought there was | 07:44 |
| dcaliste | Eh, yes, there is https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/45 | 07:45 |
| dcaliste | It is tagged as WIP wecause I would like to test it further, particularly on real servers. | 07:46 |
| dcaliste | But you can review it already, except if I find issues, I won't change things anymore. | 07:46 |
| dcaliste | It's further rewrite and simplification of notebooksyncagent (also making it this part ready for any incidences, not only events). | 07:47 |
| chriadam | I wish gitlab UI by default made the "this PR is collapsed, please click to expand" button BRIGHT RED AND BOLD so that I don't constantly scroll over it by accident and think "huh, this change seems incomplete" haha | 07:48 |
| chriadam | it had folded the notebooksyncagent.cpp diff, making me very confused for a moment there ;-) | 07:49 |
| dcaliste | Eh eh, I see, I often think that this MR looks too simple for announced commit message ;) | 07:50 |
| chriadam | I mean, the change looks good to me from a quick eyeball. I'd like flypig to have a look also if he has time. | 07:53 |
| JulianF | Hey chriadam and dcaliste just while you're dreaming of iCalendar related things and how to represent "all day", I haven't met you before, but have long been dreaming of extensions to better support real-world imprecise/fuzzy time specifications like "overnight", "morning", etc. which should be displayed as fuzzy-edged periods and not as "00:00:00.000 - 11:59:59.999". | 07:53 |
| JulianF | Ever looked to see if anyone in the world is working on such things? I assume you're basing your data model on existing iCalendar spec and not trying to support anything outside it, yes? | 07:53 |
| dcaliste | About MR!43, in CalDAV, you should also review https://bitbucket.org/jolla/ui-jolla-settings-accounts/pull-requests/40 to ensure that UI is updated accordingly when the notebook list changes. | 07:54 |
| chriadam | JulianF: currently yes, using the RFCs for iCalendar | 07:54 |
| dcaliste | JulianF: in my opinion, a first approach should be done in the UI itself, in the same way that is is proposing sensible reminder values instead of a custom overgrown widget to allow all possibilities provided by the RFC. | 07:55 |
| dcaliste | So UI is providing like "shortcuts" that internally expand to the right values to be stored and exchanged with other services. | 07:56 |
| dcaliste | chriadam: about !45, sure flypig can review it when he has time. It's not in a hurry. | 07:57 |
| chriadam | dcaliste: I will poke him. I will also check to see if there is an internal bug about caldav which might be a candidate for us to mark time again, would allow us to review that change more thoroughly / spend more time on it | 07:58 |
| chriadam | sp/again/against | 07:58 |
| dcaliste | You may find the JB about adding task support. | 07:59 |
| chriadam | JulianF: are you talking specifically about calendar events here, or more generally in terms of "communicating about datetime objects" e.g. for alarms, notifications, scheduling, etc | 07:59 |
| JulianF | chriadam: dcaliste : Thanks! Anyway, just wanted to throw that thought in your direction. Would be happy to see SailfishOS's calendar functionality get better in that way. But I think what you can do while keeping within iCalendar is quite limited. | 07:59 |
| dcaliste | Because part of the commits remove the event specificities from notebooksyncagent. (but some elements remain in incidencehandler and reader.Cpp). | 08:00 |
| JulianF | chriadam: Both. Same applies to all kinds of time specifications. A use case where I ran into this is I used a little FOSS resume/CV generator, and I typed in that I worked in one job from 2008 to 2009, and it displayed my resume saying I worked from "1st Jan 2008 to 31 December 2009" which is *not* correct! | 08:01 |
| JulianF | (That was a little Perl app, or something, I forget, anyway not on Sailfish.) | 08:01 |
| chriadam | JulianF: right. I guess it is something which is at the level of QDateTime | 08:02 |
| chriadam | some "descriptive time" which can then be mapped to a specific QDateTime in a specific timezone | 08:02 |
| chriadam | I guess my response would be: it's an interesting idea, but unlikely that we would have resources to spend on it currently, except perhaps as dcaliste mentions in terms of adding some "commonly used" ones to the calendar UI and then manually mapping it to the appropriate dtStart/dtEnd values for the device's current timezone | 08:03 |
| JulianF | Sure. I just want to make various people working in this area aware of the issue. It needs some global standard, I think, so a task https://www.calconnect.org/ should be doing, but I don't know if they are. | 08:04 |
| JulianF | Thanks for listening! Sorry for the interruption. | 08:05 |
| dcaliste | JulianF: no problem, it's an open channel ;) | 08:05 |
| JulianF | Glad to learn you have some degree of event specificities at all. I didn't know that existed. | 08:06 |
| chriadam | dcaliste has been fixing bugs in the way we handle all day events, for example | 08:06 |
| chriadam | but aside from that (i.e. floating timespec events which always go for 24 hours from midnight on one particular day, no matter which timezone you're in) we don't really have UI support for these sorts of things yet, I think | 08:07 |
| JulianF | Ack. | 08:08 |
| chriadam | dcaliste: I've added a note about JB#1104 to that caldav MR - thanks. we will mark some time there. | 08:09 |
| chriadam | haha shows how old that ToDo support task is... bug number only has 4 digits | 08:09 |
| dcaliste | Indeed, wouhou, I can add a Contribues to the commit message. | 08:10 |
| chriadam | ;-) | 08:10 |
| dcaliste | chriadam: one last thing, about the GPG landing in public release (that's great), do you think I have permission from Jolla to advertise it a bit further on TJC, in particular writing how to install it and test and use it ? | 08:13 |
| dcaliste | Or they prefer to organize comm by themselves on it ? | 08:13 |
| chriadam | I was about to mention, Jaymzz is currently drafting a blog post tentatively titled Community Contributions Spotlight or similar, which is hopefully going to be released this month | 08:14 |
| dcaliste | It is mentioned in the release notes which is fine, but without further explanation, so beside me, I'm afraid there will be few feedback ! | 08:14 |
| chriadam | it will include the changes you made, and also changes from piggz on camera/droidmedia stuff, and some hardware adaptation contributions | 08:15 |
| dcaliste | Ok, so I'm waiting for jaymzz, no problem. That was the target of my question. | 08:15 |
| chriadam | he will send you (and the other contributors) a draft in the near future | 08:15 |
| chriadam | also will give us "room" to provide instructions on how people can test it on their devices, where it might have gotten lost in the big release blog post, I guess | 08:15 |
| dcaliste | That's fine, I didn't want to bypass some official channel if it was in preparation. | 08:16 |
| dcaliste | Indeed, it will have better exposure like that. | 08:16 |
| chriadam | dcaliste: in general I would say: you can advertise the feature however you wish, you contributed it after all. but yes, we have an official blog post in the pipeline about it :-) | 08:16 |
| chriadam | sorry that we were lax on comms. there was big crunch to get 3.1.0 out with lots of final polish fixes required, and now half of finland is on vacation at the moment, so things have been... interesting. | 08:17 |
| dcaliste | I was not afraid of being forbid, just wanted to avoid duplicating effort if official communication was in preparation. | 08:17 |
| chriadam | yep :-) | 08:18 |
| dcaliste | So far so good then, waiting for jaymzz and wish nice summer vacations to Finns. | 08:18 |
| dcaliste | Thank you chriadam for the checkpoint today, I guess we didn't forget anything (email folder sync can wait a bit further for pvuorela). | 08:20 |
| chriadam | indeed, thank you! yes, and the jolla-calendar PR will wait for Pekka also | 08:21 |
| chriadam | I hope you have a good week | 08:22 |
| dcaliste | Thanks, you too. See you next time. | 08:24 |
| *** Renault_ is now known as Renault | 14:05 | |
| attah | Could someone please check that my gstreamer packages look "default"? https://pastebin.com/fAzjKgCs | 17:59 |
| attah | Having issues with video lag... | 18:00 |
| mal | attah: what is that gstreamer1.0-plugins-base-apps ? | 18:06 |
| mal | attah: it's not installed on my device | 18:07 |
| attah | hmm, okay | 18:07 |
| mal | but doesn't seem to contain much | 18:08 |
| attah | are you by any chance not on 3.1? | 18:08 |
| attah | Install Date: Thu Jul 18 21:18:51 2019 | 18:08 |
| mal | 3.1 | 18:10 |
| mal | attah: just out of curiosity try removing that | 18:10 |
| mal | if that changes nothing check journalctl anbd logcat for anything interesting | 18:11 |
| mal | attah: which app do use you use playing videos? | 18:11 |
| attah | Primarily the native browser, and youtube in that | 18:11 |
| mal | *for | 18:11 |
| attah | and setting quality up a notch or two from the often-default 360p | 18:12 |
| attah | Also my own S''Play | 18:12 |
| mal | do you have libav installed or something like that | 18:14 |
| attah | Nothing more than some thumbnailer related thing | 18:15 |
| attah | uninstalling baseapps did nothing immediate | 18:15 |
| mal | what exactly? | 18:16 |
| attah | nemo-qml-plugin-thumbnailer-qt5-libav-0.0.10-1.3.1.jolla.armv7hl | 18:17 |
| mal | ok | 18:17 |
| mal | so then I need logs | 18:17 |
| attah | journalctl did zippedidoda last time around | 18:17 |
| mal | attah: was this xa2 or some other device? | 18:17 |
| attah | how do i logcat? | 18:18 |
| attah | xa2 | 18:18 |
| mal | /usr/libexec/droid-hybris/system/bin/logcat | 18:18 |
| attah | not a single line produced while watching stuttering playback | 18:20 |
| attah | but some rolled out initially | 18:20 |
| mal | it should usually only print things when you start playback, preferrably get logs before you try to play first video after reboot | 18:21 |
| attah | how is your 720p playback? | 18:21 |
| attah | ok, will do | 18:21 |
| mal | attah: how can I see what the quality is? | 18:23 |
| attah | upper right corner menu, playback settings | 18:24 |
| mal | in youtube in browser for example | 18:24 |
| attah | video needs to be playing, or you'll only see speed settings | 18:26 |
| attah | logcat: https://pastebin.com/rX20LrYi | 18:28 |
| mal | attah: hmm, looks like it's using some software codec, wondering which one | 18:32 |
| attah | for you, me, or both? | 18:33 |
| mal | for me also | 18:36 |
| mal | I never noticed that before because I rarely watch videos on phone | 18:37 |
| mal | I'll have a look what is happening | 18:48 |
| attah | much appreciated, let me know if i can help somehow | 18:49 |
| attah | could be vp8 or vp9, apparently the phone reports support for it | 18:51 |
| attah | no ide what the acceleration situation is there though | 18:51 |
| mal | could be those are used instead of h.264 | 18:53 |
| attah | but then again, i'm pretty much certain svtplay uses h264, and that too has a bit of lag | 18:53 |
| attah | checking now whether that looks like buffer issues rather than anything else | 18:54 |
| mal | using "GST_DEBUG=droidvdec:5 some_app" as nemo user should tell if hw codec is used | 18:55 |
| attah | Yeah, i think svtplay is a false positive for lag, my rate setting is out of play, and some lag is expected when changing hls bitrates dynamically | 18:59 |
| attah | hmm, that debug setting does not produce a whole lot of output around video playback time | 19:02 |
| attah | so software then i assume | 19:05 |
| mal | attah: I verified that vp8 and vp9 are using sw codec, h.264 is using hw codec | 19:05 |
| mal | which means youtube must be using vp8 or vp9 | 19:06 |
| attah | it certainly does on my desktop | 19:06 |
| mal | the real question is why it's not using the vp8 provided from android side which is also available | 19:10 |
| attah | it could be running vp9... is that available too? | 19:12 |
| mal | I tried both vp8 and vp9 on another site | 19:13 |
| attah | yes, but is there an android version of vp9 available too? | 19:14 |
| dragonchaser | Hey | 19:15 |
| dragonchaser | I am having a weird bug on my xa2. the statusbar is gone (no clock, battery level etc) anybody a clue why this is happening? | 19:16 |
| mal | attah: I think I found the reason, browser engine has builtin vpx decoder | 19:20 |
| attah | oh, feels like one would want to disable those | 19:21 |
| mal | might be | 19:22 |
| mal | need to discuss that with others | 19:22 |
| attah | I tried the build instructions from https://github.com/sailfishos/sailfish-browser/wiki/BuildingInstructions just now... and i needed to add a version number to the target for the first steps | 19:22 |
| attah | then failing at actual building due to some missing lua script | 19:22 |
| attah | should the instructions still work? | 19:23 |
| mal | not sure, I mostly build things on OBS | 19:24 |
| attah | mal: thanks to your insight i have formulated a workaround, disabling "webm" in about:config | 19:31 |
| mal | attah: what makes youtube work better? | 19:46 |
| attah | https://together.jolla.com/question/210723/psa-workaround-for-laggy-youtube-playback-in-native-browser/ | 19:46 |
| attah | tl;dr h264 | 19:46 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!