Removed 'Waiting for track information...' from music player

[n0toose]

Not sure if this should be combined with another visual indicator, but most music players (e.g. VLC) really don't include anything when nothing's playing, and the text feels excessively technical and/or confusing for average users. I'm sure that everyone else can discern whether Gadgetbridge or another companion app is managing to send notification data properly, even without any output. The text is also too long and gets cut off from the screen.

[n0toose]

I'm currently messing around with the codebase and making some small visual changes based on things that bother me, since I haven't been able to prepare a means of testing my changes yet before I move onto something bigger.

[n0toose]

I just spotted a bug with the Transistor web radio app that's available on F-Droid:

Initializing a set of specific label and having only one of them get overwritten is an edge case that's currently not being considered.

[Avamander]

Blank is bad, because we'll, it makes it look empty and users have no idea that nothing has been received yet.

Companion apps can be updated to send an empty string if just the artist is missing.

[n0toose]

Blank is bad, because we'll, it makes it look empty and users have no idea that nothing has been received yet.

Isn't blankness alongside with the timestamp a bit obvious? Obviously, I'd like for the buttons to turn gray too, but I didn't touch that because I'm not sure how and there's #269 that's already in progress. I think that blankness or simplicity is good, because it sends the right message: There's nothing!

I believe that InfiniTime is the deviant here as far as this topic is concerned, unless if you include conventional MP3 players like the ones you find in cars as well.

Companion apps can be updated to send an empty string if just the artist is missing.

Companion apps should just send whatever information they receive instead of processing everything in their own individual ways, leading us to a slippery slope where we have to deal with what each and every single companion app does, if that's even possible! Companion apps should relay and not process information unnecessarily; The companion app isn't sending anything about the artist string, so it should be fairly obvious that the artist clearly doesn't exist. Other devices handle it sufficiently, so why should InfiniTime specifically retain outdated, per the app, information? Why should the companion app go along with an idiosyncrasy that's by no means immutable in our scenario?

[Avamander]

Isn't blankness alongside with the timestamp a bit obvious?

No, not really. They will most likely think the watchapp is very broken. This PR worsens UX.

Companion apps should just send whatever information they receive instead of processing everything in their own individual ways. Companion apps should relay and not process information unnecessarily;

They already do have to preprocess the data, filter and adapt it to the OS' needs. They have to do it because it makes more sense to do that on their side, it's faster, more battery efficient, user-friendlier and flexible. I recommend you familiarize yourself a bit how for example Gadgetbridge works across 20+ supported devices.

, leading us to a slippery slope where we have to deal with what each and every single companion app does, if that's even possible!

No, not really. The companion apps will always try to cater to the best interests of the watch, not the opposite.

Other devices handle it sufficiently, so why should InfiniTime specifically retain outdated, per the app, information? Why should the companion app go along with an idiosyncrasy that's by no means immutable in our scenario?

InfiniTime is not retaining outdated information because it doesn't know it is outdated. A companion app however does, and can push that information to the watch. Keep in mind that not all updates are full updates, that'd be absolute lunacy.

[n0toose]

No, not really. They will most likely think the watchapp is very broken. This PR worsens UX.

Fair, I agree. I was quite skeptical of my change as well initially, because it should probably be combined with another visual hint. I'm not a big fan of text. Would it be possible to change the text to something that's more human-readable like "Nothing's currently playing" or a stand-by/loading animation like the ones you'd see in PlayStation 2 consoles? If the user is clearly trying to control a song and it isn't working, they'd probably figure out that something doesn't work right, but I'm not sure I get why they would immediately shift the responsibility onto the watch.

I recommend you familiarize yourself a bit how for example Gadgetbridge works across 20+ supported devices.

I can assure you that I am capable of understanding that the simple idea that each OEM with their own custom apps does weird stuff, and that's why I believe that following on their footsteps is a bad idea...

No, not really. The companion apps will always try to cater to the best interests of the watch, not the opposite.

... especially because Gadgetbridge isn't the only companion app that exists or is going to exist, and having each developer develop their own system for comparing previous metadata and deciding not to send it if there's a match when there's more firmwares other than InfiniTime out there sounds bad and poses a tough maintenance burden with a lot of edge cases and visual bugs that are difficult to account for for the sake of abiding with the conservative mindset of embedded development and saving a few bytes. Are all these combined work hours really that worth it?

I believe that the scenarios where those bugs would appear (e.g. using a music streaming service (full metadata), then an unspecified news app (artist, maybe duration), then an unspecified VOD streaming app (duration, probably no title/artist)) definitely outnumber the two scenarios of "I'm listening to a radio station and the title doesn't change" and "I decided to sit through and listen to the entire discography of a single artist consecutively", but that's something I addressed in #279.

InfiniTime is not retaining outdated information because it doesn't know it is outdated. A companion app however does, and can push that information to the watch. Keep in mind that not all updates are full updates, that'd be absolute lunacy.

I could bring up other examples of music players or programs that otherwise control music under very strict resource constraints that still read and parse the data of each file individually, such as homebrew applications for the Atari.

Either way, the "Waiting for" text definitely seems superfluous and very prone to doing things as seen in my picture. I severely doubt that leaving it all up to the companion app could fix this visual error in a simple manner.

[Avamander]

I can assure you that I am capable of understanding that the simple idea that each OEM with their own custom apps does weird stuff, and that's why I believe that following on their footsteps is a bad idea...

The point was more that devices vary and they inherently need different approaches, there's no one-size-fits-all because the devices aren't all the same, can't be the same and probably never will be the same.

and having each developer develop their own system for comparing previous metadata and deciding not to send it if there's a match when there's more firmwares other than InfiniTime out there sounds bad and poses a tough maintenance burden with a lot of edge cases and visual bugs. Are all these combined work hours really that worth it?

Too bad, you can't do without such processing and yes, they are worth it. The amount of updates a music player sends by-default is usually very high, it would decimate the battery life. The time you spent in this thread already is higher than the amount it would take to write a fix for three companion apps.

visual bugs that are difficult to account for for the sake of abiding with the conservative mindset of embedded development and saving a few bytes

It isn't a desktop PC where those bytes don't matter or where battery life isn't a concern.

I believe that the scenarios where those bugs would appear (e.g. using a music streaming service (full metadata),

It isn't a problem with such music playback.

I could bring up other examples of music players or programs that otherwise control music under very strict resource constraints that still read and parse the data of each file individually, such as homebrew applications for the Atari.

Not a relevant example.

Either way, the "Waiting for" text definitely seems superfluous and very prone to doing things as seen in my picture.

It's a necessary UI element for better UX, issues with anemic data from music players can be fixed on the companion app side, trivially.

[n0toose]

Yeah, you're right.