All tracks show additional 30 minutes

[jesus2099]

I couldn’t reproduce that with same versions as him but fmera has this problem in Firefox 35.0.1, Greasemonkey 2.4.

When the track times display gets changed to milliseconds display, he obtains 30 minutes time too much on both local and remote tracks.

[jesus2099]

I still don’t see this happening.
The code has changed maybe it won’t happen any more for fmera either.

[jesus2099]

Now I can see it at those edits (fmera again).

[jesus2099]

Again and asked for fmera’s help in https://musicbrainz.org/edit/43570372 as I never had this bug myself but he keeps having it all those… years !

[fmera]

now on Firefox 51 on OS X 10.9.5 (Mavericks)

tested with just GM 3.9 and mb. MASS MERGE RECORDINGS 2016.6.15 enabled, still same problem.

no problems even up until the moment i click the "mass merge recordings" button to activate the panel, but the track times all instantly increase by 30mins the moment i paste the url of the source release.

[jesus2099]

It must have something to do with OS X’s port of Firefox, then…
I don’t reproduce with FF 51 + GM 3.9 on Windows XP…

[jesus2099]

@fmera, could you test this new version there?
Click the above commit link (or f4c9ef3), then View then Raw to install it.

[jesus2099]

Sorry, try this later one (66fd017) instead. :)

[fmera]

nope, still showing the +30min…

but it's no big deal, i've already gotten used to it after all these years!

[jesus2099]

Really?
What does it show instead of 19:06 in https://musicbrainz.org/release/491eb8fc-e358-4e84-8db6-e0409a6a7661 ?

[fmera]

49:06

[jesus2099]

@fmera, are you in a 30 minute shift time zone? What is your time zone?
Could you test this latest version (fa6e569 → View → Raw) and copy / paste me what you get in the JavaScript console, please?

[jesus2099]

Just try the same release on itself: https://musicbrainz.org/release/491eb8fc-e358-4e84-8db6-e0409a6a7661 and then shift up and down the remote tracklist to check if both local and remote times are now correct or not. :)

[fmera]

will retry when i'm free, but it's no big deal really. don't waste too much tme figuring it out ;) anyway, i'm not in a "30min" time zone, full hour time zone. but what has time zones got to do with track times anyway?

then shift up and down the remote tracklist to check if both local and remote times are now correct or not. :)
don't think that will have any effect, as i've been doing that fairly often, to align tracklists between releases that are displaced. it won't cause the 30min error to go away.

will get back to you when i've tried the above fa6e569…

[fmera]

rejoice!!!! ;p

your fa6e569 (2017.2.20) finally did the trick. the +30min bug is gone. how is it different from the latest regular update of your script?

[jesus2099]

Thanks for the test, I will integrate this change to the main branch, that was indeed updated recently (I don’t remember for what feature). 👍

[jesus2099]

Hello @fmera,
Do you sometimes use the track time parser from SUPER TURBO in release editor?
It seems maybe it could have the same 30 minute problem:

konami-command/mb_SUPER-MIND-CONTROL-II-X-TURBO.user.js

Line 1644 in 22471b7

time = (date.getHours() * 60 + date.getMinutes()) + ":" + (date.getSeconds() < 10 ? "0" : "") + date.getSeconds();

[fmera]

no, i don't have that script installed. good luck with the fix!

[jesus2099]

In the devtools, Sensors tab, I can stimulate being in a timezone with minute shifts (not only hours), like @fmera.

AU	−1228+13050	Australia/Darwin

In the IANA list, Darwin has an easy to remember name.