Focus mode format mp3, <=128 kbps incorrectly list mixed track format album with 320kbps files

I’m cleaning up the library, (getting rid of old low res mp3) …
I focus on mp3 format + restrict Lossy Files To Bitrate 32- 128.
Yet the first album listed is a one that holds ALAC 44.1 16 bit + several mp3 320kbps.
looks like a bug to me…

Did this mixed format album also contain tracks there were MP3 <=128 ?

If so then I believe the filter is operating correctly, as it is finding albums with those tracks and listing them.
(The format of the other tracks on the album are not relevant to the filter).

my apologies for not being clear enough…
I mentioned the mixed track format because I believe it is relevant to the bug.
but obviously all mp3 in that album are 320kbps only.

If the format filter is displaying albums that contain at least one track that is “MP3 <=128” then it working. The presence of any other higher rate tracks in a given album does not affect the result. I don’t see a bug here, though I appreciate in your use case it not what you wish to achieve.

Including / Excluding mixed track format albums from the search may help:

  • Focus --> Inspector --> Multiple Audio Formats (and then as required, click filter tag to invert it)

Examples:
image

image

image

1 Like

I think there is a misunderstanding.
my filter is simple: mp3 and <= 128kbps.
it wrongly list one albums that does not contain ANY nor a SINGLE MP3 below 320kbps.
So yes I believe there is a bug.

frankly this doesn’t represent any major friction, but I though I’d be nice and report the bug :slight_smile:

Agreed that’s not right, which album is it?


only extra tracks are in mp3

Thanks for the example (I’ve got that album as well but mine is a straight 44.1 FLAC from CD rip.)

I’ve just setup focus as you did,
image
and have checked the returned albums one by one, all 71 of them.
All looked good … until the penultimate album:

Weather Report - 8:30
Disc 1 is FLAC 44.1kHz 16 bit
Disc 2 is MP3 44.1kHz 160kbs

So nothing 128kbs or lower.

Let’s tag @support to follow up with you.

Disc 1


image

Disc 2

I just wanted to point out that the bug is still present in the latest version (1.5 b354) , and @support never did follow up

Hey @thibaud_Van_Vreckem,

I wish to offer my sincere apologies for the delay here. I’ve sent a report with the information you’ve provided above over to the technical team for further investigation. I’ll be sure to update you here once I’ve received their feedback.

Thanks!

Hey @thibaud_Van_Vreckem,

Would you mind sharing one of the albums that’s experiencing this behavior with us?

Ideally, you can zip up the entire folder and send me private message containing a shared dropbox link. If you don’t have Dropbox or need another way to send the media, just let me know.

Thanks!

@support,
I know this issue is in no way high priority, but having it unresolved after more than 6 months (considering - I’m guessing a 5 min fix bug) has to keep you wondering about the bug fixing process.

I reported this issue 1 Year and a half ago.
I got a response from @dylan 6 months later. and supplied the requested medias.
One year later, No news, and the bug is still present in 1.6 ( build416 )
I do appreciate Roon a lot but I must say the way Roon @support is being handled is making me sad.

This isn’t the support team – they did their job and passed me the bug report. The report is still open in our tracker, but it’s not currently scheduled for an upcoming release.

Every bug fix requires time from developers and from QA to ensure the issue is resolved and doesn’t cause any additional regressions. This doesn’t doesn’t come up very often, so it’s a likely candidate to be cut from the schedule as we prioritize issues. That said, I’ve made a note to look at getting this done after the next release ships.

Thanks for the nudge, and for your patience @thibaud_Van_Vreckem.

1 Like