File size to be copied to devices is based on source files, not the encoded file size

[whatwareweb]

• [x] I have checked the FAQ for answers.
• [x] I have checked the Changelog that the issue is not already fixed.
• [x] I believe this issue is a bug, and not a general technical issue, question or feature requests that can be discussed on the forum.

Describe the bug When copying music to a device, Strawberry automatically encodes songs that are not able to be played on the target device. However, it does not check the file size of the resulting encoded files, which results in an inaccurate prediction of the amount of storage on the device that will be occupied by the new music. This leads to either the device not having its full storage capacity being able to be used, or files failing to copy because there is no more room on the device.

To Reproduce Connect a device that only supports specific codecs, and add files to the library that are not supported by the device. The storage space that strawberry shows the music will take up will not be the same as the used storage space on the device.

Expected behavior Strawberry could encode the audio files first, before showing the file size that would be resulted in by the music that the user is attempting to add to the device.

Screenshots: Used file space that Strawberry predicts:

File space that is actually used once the files are encoded and copied over: Note the iPod in these screenshots only supports AAC and MPEG codecs and I copied over mostly FLAC format songs

System Information:

• Operating system: Fedora 39, kernel 6.7.6-200.fc39.x86_64
• Strawberry Version: Version 1.0.23

Additional context N/A

[jonaski]

It's true that the calculated free space will be slightly off, but transcoding the files before showing the dialog will obviously take time, and I honestly don't think it's worth it just for showing the dialog. In most cases you can copy some albums first, then try another albums which will show the dialog with the recalculated space.