fix 96kbps playback issue

[fivebanger]

Fixes 96kbps issues (fixes #1433 (comment))

[photovoltex]

Oh damn it. These types where removed by the protobuf update. Anyhow, wouldn't it be better to re-add the types discussed here #1236 (comment)? And could we add an comment somewhere in the proto file, so that we don't remove it accidentally again?

[kingosticks]

Maybe we could come up with a test that just checks all the format types arer there?

[fivebanger]

Anyhow, wouldn't it be better to re-add the types discussed here #1236 (comment)? And could we add an comment somewhere in the proto file, so that we don't remove it accidentally again?

Unfortunately I still have no clue where all those type definitions come from and if they are valid or not. I thought the missing definitions have been removed by intention. I'll add

        AAC_160 = 10;
        AAC_320 = 11;
        MP4_128 = 12;
        OTHER5 = 13;

later on again.

[photovoltex]

Is the unknown type still required then?

[fivebanger]

Is the unknown type still required then?

What I remember from the original discussion the UNKNOWN should act as a default value, otherwise we may run into issues again (especially for 96kbps, since that's the first value and gets overwritten by unknown types). Pls. check #1236 (comment) and following. Since the UNKNOWN seems not to harm anything I would vote for keeping this approach, even though I have checked that my examples would also work without the UNKNOWN definition. According to my understanding, any new (and therefore unknown) type definition which is not covered by the .proto definition would overwrite the 96kbps file_id again and 96kbps streams would not play.

Edit:
After recalling all the details from the original discussions, I think the question is not whether to keep or not to keep the UNKNOWN approach (we should keep it). The question is which definitions in the .proto files may suffer from the same issue in case Spotify returns a value that is not covered by a .proto type definition and gets mapped to default (thereby erroneously overwriting the first value).

[photovoltex]

Personally I would prefer to not modify the proto files from the extracted version. But as long as it's working and is tested I would also be fine as it is.

So @fivebanger please add a small test that checks for the default value and the additional types so that we don't run into the problem again when we update the proto files. It would also be helpful to have a reference to the initial issue or PR somewhere in a comment around the test.

[roderickvd]

It does seem brittle. Would it work if to try and parse it as an Option?

[photovoltex]

I just looked at the issue in detail again. The tl;dr; is to adjust the impl From<&[AudioFileMessage]> for AudioFiles in metadata/src/audio/file.rs to handle a given format as EnumOrUnknown instead of just calling .format() because that doesn't handle unknown cases properly.

The explanation in detail:

The audio format is already send as Option, but we only check if a given audio file has a format and not if the format is know as one of our enum variants. Because we just call .format() (which is generated by protobuf) the possible unknown variant is ignored and the "default" variant (OGG_VORBIS_96) is used, which for an enum seems to be the first variant. As a map can't have multiple items with the same key, the last audio file with OGG_VORBIS_96 wins, which might not be the correct file and by that can't be loaded as what it says to be/

You can see the issue pretty well if you look at snippets from the format printed to the console:

// a known enum variant
format: Some(OGG_VORBIS_96)
...
// an unknown enum variant with id 13
// 
// that also explains why adding the other formats fixes the problem
// as they don't overwrite OGG_VORBIS_96 anymore because they are 
// not anymore mapped as the default
format: Some(13)

---

@fivebanger Friendly bump to add tests for the changed protobuf defintions, or adjust the changes to only fix the code part. If you need help or have any questions feel free to ask anytime :)