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.