-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Recorder] Day in filename is often wrong #3135
Comments
I think storing the date as UTC is a good choice, but I would try to display the date (the one with class card-subtitle text-gray) in local time, or? Edit: Looks like it is in local time. So what is the issue here? Storing in UTC and displaying in local time is a common pattern. Btw: Do you really have "sched" installed two times?!? |
The issue I was having was with the file names. The recorder wouldn't append to the file because it expected the file to have a different name and would instead create a new file. Say, for example, I start recording at 23:35 utc (15:35 local time). I then stop recording at 23:55 (15:55). I record again at 00:05 (16:05), and the recorder creates a new file instead of appending. Yes, It would appear I have sched installed twice. I'm not sure how this happened and I'm a bit afraid to remove one of them. |
For recorder, I propose we fix this with a change to the logic - currently we'll see if there's any logs for the current day. Instead I propose that we look at the most recent log and if it's within 4 hours (for example), we offer to resume that log. This would also fix the issue for anyone (regardless of their timezone) who starts recording before midnight and wants to resume said recording after midnight. What do you both think? Unrelated - @Mineinjava, for S=require("Storage");
S.list(/\.info$/).forEach(fnam => {
var j = S.readJSON(fnam,1)||{};
console.log(JSON.stringify({id:fnam.slice(0,-5),ver:j.version,fnam}));
}) |
Four hours seems reasonable. However it may be useful to make it configurable. |
This outputs: Long code block
|
We now look at the latest log's last timestamp - if it was within four hours, we prompt the user to resume recording to that file. Fixes espruino#3135
I've got a draft fix (#3136), if you'd like to try it out, it's deployed to my gh pages. I think the four hours logic will want a setting, but let's see how well this works.
Thanks for that - a file shouldn't appear twice so I'd guess this is a partially corrupt storage situation. You might want to backup anything important on your watch. @gfwilliams what do you think? |
That file has been that way since I got the watch. Weird. |
The duplicate scheduler app can be fixed by doing a backup and restore from the app loader. There's more info on it here https://forum.espruino.com/conversations/388915/ |
Affected hardware version
Bangle 2
Your firmware version
2v19
The bug
From my experience, about 50% of the recording files have a name that is a day later than the date it was recorded on.
My timezone on watch is set to GMT-8. This is likely the cause of the issue.
Installed apps
widlock (0.08), sched (0.22), sched (0.22), widalarm (0.01), messageicons (0.05), boot (0.59), notify (0.13), clock_info (0.07), gpsinfo (0.12), bikespeedo (0.06), gpsnav (0.08), dtlaunch (0.24), bwclk (0.33), widmsggrid (0.05), widminbt (0.01), widgps (0.09), slides (undefined), magnav (0.06), quicklaunch (0.15), runplus (0.22), kbswipe (0.09), clkinfostopw (0.03), mylocation (0.10), clkinfosunrise (0.03), configurable_clock (0.03), locale (0.17), sleeplog (0.15), widclk (0.08), gpsmagcourse (0.01), waypoint_editor (0.03), rebbleagenda (0.01), weather (0.26), clkinfocal (0.02), ios (0.15), waypoints (0.03), setting (0.68), messagegui (0.75), messages (0.62), fastload (0.06), fastreset (0.03), flashcount (0.01), widbatv (0.03), alarm (0.46), health (0.28), openstmap (0.27), recorder (0.37), myprofile (0.01)
The text was updated successfully, but these errors were encountered: