Display more info with “mb. INLINE STUFF”

MusicBrainz
24

LOL - and there was me trying to carefully get the terminology right, and missed that last one.

(And yes - I knew the counts were wrong. They are more wronger now as I’ve been updating some…)

1 Like
25

For those who came across some releases that would completely freeze their browser, an INLINE STUFF performance bug has been fixed today, and it should no longer happen.
Thanks to @Mitch2323 for suggesting an important clue on how to fix this old bug:

4 Likes
26

Daft question - do these scripts auto-update (I am using ViolentMonkey)?

1 Like
27

Yes they should!
Check if your script has version 2018-12-31 and if not, force the update. :slight_smile:

2 Likes
28

The Monkey said “Yes, all is updated”. I can see the new version details at the top of he script source. :sunglasses:

1 Like
29

Hello INLINE STUFF

Quick question @jesus2099 about the AcoustIDs that INLINE STUFF puts on screen. Will they have an effect on this: Adding rate limiting to the AcousticBrainz API

When I open up a five CD set with 20 tracks on each disk that is at least 100 AcoustID items being pulled from somewhere. Just curious if this is coming via that API? I may toggle these off on my screen if they are as I rarely look at those numbers or interact with them.

1 Like
30

AcoustID is not the same as AcousticBrainz. If you are specifically asking about AcoustID, then there’s no problem because it’s unrelated.

4 Likes
31

And also, even for big release, I batch call for many AcoustID at once, IIRC. :slight_smile:

1 Like
32

I have the feeling a name was badly chosen, confusion is recurrent :wink:

2 Likes
33

Hello again nice INLINE STUFF userscript. Very handy. Thanks again for your time saving and error spotting abilities.

BUT there is a new update that clashes a bit with what I work on. Can I disable single features of the addon?

Look at the confusion caused by the attempt to spot Recording length errors. These are combinations of bootlegs, vinyl and reissues in here. Everything is marked as “not equal” which is misleading and odd.

Can we adjust the error range of this check? Or even better, just disable it?

INLINE STUFF is great, so I don’t want to disable the whole Userscript. Just remove this feature as bootlegs just are not that accurate. :slight_smile: Thanks.

I’ve also never understood which time is getting chosen to be the set time up there in the corner as it matches none of the releases on the page. Even if the slack was a couple of seconds either way would help.

Okay, now you have confused my Maths OCD. Why is this Recording not being flagged like the one above? The Recordings towards the bottom are three seconds out… does it only do the first dozen?

For me, a perfect solution would be a 10% margin of error. I am trying to read and understand the script and it seems to work on exact matches. Don’t think I even see that when working with only CDs from the same manufacturing plant. :smiley:

Or am I making this break because I have a script that displays thousandths of a second for CDs? (I am investigating and updating this post as I learn more…)

2 Likes
34

Thanks for your good remarks.
I will answer them soon.

Just to explain last update a little bit.
It is the result of the merge (as is) of another script that apparently you were not using.

And also, highlighting does not mean error.

1 Like
35

HAHA - you try telling my OCD that. :crazy_face: :rofl:

Thanks for listening. I am in no rush.

1 Like
36

Yes, in fact, I never see my yellow marks as errors but as interesting bits.
But you’re right it would be more useful to highlight potential errors, indeed, instead of flooding the display with fancy blinking lights.

I see that MBS is warning when there is 15 seconds or more of difference between two recording lengths.

I think I should change the script to display 15+ seconds diff as errors (red) and 5+ seconds (a third of error) as .name-variation (current light marks).

Here is the initial ticket, implementing automatic recording times.

Thanks very much for your insight, I never noticed this one in 7 years!
I should change the script to check more than 25 tracks! :grin:

Disc ID set milliseconds to track length, but these are never shown in MBS (only in web service / API).
They are revealed by the userscript! :face_with_monocle:

BTW, your STAY example shows that all tracks that have a Disc ID, are exactly 4:05.333 same as recording computed length. :wink:

4 Likes
37

Thanks @jesus2099 - I’ll read this closer in the morning when the brain can process it better.

The “15 seconds or more” warning from MBS is a bit random. I would have thought a percentage error would make more sense. Maybe I am just editing long Recordings :grin: 5 seconds really isn’t much of a difference when it is common to fade a track out on a bootleg.

For me both of these times are too short would just flood too much noise into the userscript and I’d be back trying to work out how to mute it.

The ticket that says “average recording times” isn’t what I observe. I’ve see it take the time of one, and ignore the other. (but too tired to find that example now and it is OT)

Glad I could spot that “check more than 25 tracks” would be useful.

The milliseconds being revealed was added by a userscript, but no idea which one. Is it this one? That is very useful to telling CDs with discIDs and Vinyl apart. Often I find Vinyl with typos (or a typo on the cover art)

Something is broken on my Stay example as I am missing all my milliseconds on those tracks. Still visible on Embryo. Eh? Yeah - too late for my head to solve those now and very OT.

2 Likes
38

Exactly my thought, it was only after expanding the hidden comments that I saw the final decision was to use the median track length, not the average :grinning_face_with_smiling_eyes:

2 Likes
39

Since the last update my inline stuff has broken on Opera + Tampermonkey
can I roll this back to previous version.

trying a fresh install on firefox + Violentmonkey
doesn’t at all, gives
“Error loading dependencies.” (infact most your scripts do)

Thanks for the hard work @jesus2099

1 Like
40

Did a bit more digging

Greasemonkey reports
User script download failed

null at https://cdn.jsdelivr.net/gh/jesus2099/konami-command@ab3d205ab8a9897ac3ef23075fda26bed07ca342/lib/COOL-BUBBLES.js?v=2016.6.1.1310
null at https://cdn.jsdelivr.net/gh/jesus2099/konami-command@4fa74ddc55ec51927562f6e9d7215e2b43b1120b/lib/SUPER.js?v=2018.3.14

I think it’s a DNS issue
FYI

1 Like
41

You don’t have access to https://cdn.jsdelivr.net with your browser, now?

These URL are necessary as long as I stay in greasyfork but I plan to leave both Greasyfork and Openuserjs sooner or later.

If you cannot access these URL, you can (re)install the scripts from GitHub and then replace (in the // @require lines):

https://cdn.jsdelivr.net/gh/jesus2099/konami-command@

by:

https://github.com/jesus2099/konami-command/raw/
1 Like
42

jsdelivr.net is skcetchy for me, sometime works, sometimes not
currently getting “ERR_CONNECTION_REFUSED” on Opera (Chrome)
Thinking my ip might be blocked,I have even tried various vpn across the globe.

Earlier on worked and the scripts installed and are currently working now.
Thanks, sorry for the bother.

1 Like
43

I’m very embarrassed to say but it was all my fault!
Not sure why, but I had block on the site in my hosts file, I’ve now comment it out

127.0.0.1 cdn.jsdelivr.net

so now all is good, feel such a fool.
Please accept my sincere apologies.

5 Likes