Looks like you forgot a few things that are required in reporting of bugs: Version info, platform and debug or trace log files.

Seems this is happening because the files cannot be matched to tracks. So this is a bug.

Got the same issue. Tried .jpg, *.jpeg, jpeg and none seem to work.

Note: Currently Lidarr only moves extra files if they have same name. This is troublesome for music and needs to be changed.

So to confirm what you're saying, if a user set "jpg,png,nfo,m3u" to import and you had files like this:

01_band-song_title.mp3
01_band-song_title.jpg
01_band-song_title.png
01_band-song_title.nfo
01_band-song_title.m3u

These files would import correctly.

However..

If files were named like this:

00_band_-_album_name.m3u
00_band_-_album_name.nfo
01_band_-_song_title.mp3
r0_band_-_album_name_insert.jpg
zz_band_-_album_name_thumb.png

Only the matched track 01_band_-_song_title.mp3 would import, despite extras seemingly covering the array of extensions.

Is this an accurate understanding of the current issue?

I think it's even worse than that, at least in nightly, in that the track import logic has been much improved but the extras logic is untouched.

So I think there would be plenty of examples similar to your first case where 01_band-song_title.mp3 is imported but 01_band-song_title.png is not.

I think it's probably best to assume that in most cases only music files will be imported at the moment.

If accurate, that's unfortunate. I'm on nightly 0.5.0.733 (should be the latest) and I noticed that track importing is much much better now, but literally no extras are being imported. I checked and after reading this issue report assumed it was related to naming structure, but I suspect you're right as before it was working as expected and now it's bringing in nothing but the music. Thanks for the insight!

Just to be clear, I don't think the extras import has gotten worse, just that it's now a long way behind the music import. We need to link the two up.

also import timed lyrics and renaming them to match the track file names would be very useful. ".lrc"

Example track and lyric file naming:

Currently no extra files are imported when specified by extension. So to resolve this, files need to be moved based on extensions set and for lyrc or synced lyrc files need to be matched with each corresponding track during the import.

The file name of the lyrc file must always match the corresponding track file name or applications like plex/kodi will not be able to use them. So when lidarr imports and renames files or just simple renames them, it must rename both the track file and the matched lyric file to work correctly.

Does anyone have a working solution to this yet as this has been an ongoing issues since I started using Lidarr.

Finally got everything else working great and thought I was going crazy here, glad to see I'm not.

+1

Gentoo Linux 4.19
Lidarr Version 0.7.1.1381
Mono Version 5.20.1.34

Nothing in debug logs even considering any of the file types I've entered.

Don't expect anything soon. And please, comments asking for updates or stating it's critical functionality are not helpful.

Any idea why this wouldn't be expected anytime soon? I started this back in 2018 (over 3 years ago) and one of the other contributors noted that this is clearly a bug. This small issue makes lidarr almost useless for anyone that needs to keep the extra files together and as other have said when a FLAC gets downloaded that is all 1 file and the .cue file is deleted now you have to delete the album, then manually grab it and manually process it (which defeats the whole purpose of Lidarr and automating things).

I see other updates being made just curious why this bug is not something the seems to be wanting to be addressed?

Any idea why this wouldn't be expected anytime soon?

The main development team is split across 4 apps: Lidarr, Prowlarr, Radarr, Readarr.
There are only ~3-4 active developers who work on this, and of those 3 -4 exactly zero work on this fulltime. Exactly zero of any members involved (developers / support) get paid to do this. Everyone of us have fulltime real jobs. Everyone of us has kids and family. Everyone of us works on more than just this project.

As you can imagine between the four projects (in addition to the various backends and other modules), the todo list is long and time short.

I can understand that. And I appreciate everything y'all do across the apps. I know for a while it felt like Lidarr had gone by the way side, but then saw a big uptick in the development on this app so I was hoping this particular issue would maybe have been a simple type fix.

Maybe when it can be worked on it would be easier to have the option to just grab ANY files that are in the folder when it is renamed and moved instead of needing to be so specific as to match exactly with the file names. That I think would alleviate all the issues (I wouldn't mind having to clean up a few unwanted files left over rather than not having any of them).

I like that stop gap idea @gold007eye. There was another I suggested above, which is not as good, but may be even easier to implement, which is to just leave the extra files in place or move to a trash instead of permanently deleting. Likewise, don’t mind the manual work to clean that up.

@bakerboy448 Understand. I think the energy on this issue is we appreciate the project, and we want the work put into the project to not be for naught. For my part, I worked for some time to try to pull code from other -arr projects to fix this, but it did not work and is beyond my skill. I also tried to use file management apps that capture the extra files, so I could propose it as a workaround here for the community. I think there are many others like me who try to help contribute, given how hard the devs work on these great projects, but it doesn’t go anywhere, so it’s invisible.

@bakerboy448 At the risk of being annoying, I see there's a lot of great activity on Lidarr develop channel these days, which is awesome. Any chance this issue can get some love in context of everything else on the list and other life commitments? Per above, I tried to work around and see if there's a simple fix in the code, but it's out of my depth. Thanks.

I would love to get this fixed.

This is now FOUR YEARS OLD! It really DOES need to be fixed. Many, many users of lidarr consider the import of .cue and .log files as necessary to the value of their collections. Surely someone in the dev group understand this?

This is now FOUR YEARS OLD! It really DOES need to be fixed. Many, many users of lidarr consider the import of .cue and .log files as necessary to the value of their collections. Surely someone in the dev group understand this?

We are aware. But comments like this remove any motivation for me at least to look into it. Pull requests are welcome.

This is now FOUR YEARS OLD! It really DOES need to be fixed. Many, many users of lidarr consider the import of .cue and .log files as necessary to the value of their collections. Surely someone in the dev group understand this?

We are aware. But comments like this remove any motivation for me at least to look into it. Pull requests are welcome.

Yes, I get it, (shut-up or fix it yourself) thanks! A quick review above reveals that you personally don't particularly like this issue nor do you appear to appreciate its impact on the community. This issue is the fourth oldest bug, and easily that with the most community comments. You may not believe it but I'm not here to raise a fuss, only to add my voice to those indicating that this is perhaps more important to the community than the devs considering it (certainly you) may believe. (If community desire does not factor in driving priority, what does?) To that end this is the last post I'll be making re; this issue. Thank you and all devs for all you do to keep these projects alive.

@ta264 @bakerboy448 and others: Just want to say that I think there are many of us waiting patiently for this issue to be resolved and that we appreciate the work you do on these -arr projects. Please do not take the ungrateful tone of others here as the default. It is indeed frustrating this issue isn't resolved yet, and clearly some people (as above) are not being constructive. This is a FOSS project, and. we aren't owed anything. I tried to figure out how to fix this and submit a pull, and I found that I didn't know enough about how these tools work. The code for handling extra files seems to be more or less the same across -arr projects, so I couldn't determine why it won't work here on Lidarr but works for others. Since this function of handling extra files important for me, I've stopped using Lidarr and have gone back to manual handling of my music library. Hopefully, it will be resolved one day, and if there's something specific that I can do to help and is within my skill and knowledge, I'd be glad to contribute.

Any chance of a bug bounty being opened for this?
It seems to be the main thing preventing some people (myself included) from using Lidarr, and I imagine a bounty would provide some incentive to fix this >4 year old bug.

I'd be down to look into this issue, but I would need some mentoring/some pointers to get started. (:

Note: Currently Lidarr only moves extra files if they have same name. This is troublesome for music and needs to be changed.

So just to clarify, the current logic only imports the files with the specified extensions if the filename matches the name of a songthat will be imported, and the fix would be to make it so that it just imports every file that has one of the specified extensions, regardless of filename?

Note: Currently Lidarr only moves extra files if they have same name. This is troublesome for music and needs to be changed.

So just to clarify, the current logic only imports the files with the specified extensions if the filename matches the name of a songthat will be imported, and the fix would be to make it so that it just imports every file that has one of the specified extensions, regardless of filename?

Correct, aaaand correct... Good Luck!

Wow, this bug is over 5 years old now. I'm sorry that I can't fix it myself, but it definitely seems like a deal breaker for all the music nerds out there (like me) who want to retain release metadata, album art, cue files, etc. :(

I've been having the same problem adopting Lidarr and the last few weeks I've been working on and off on a PR. There are some caveats, but generally it seems to work okay.

I've been having the same problem adopting Lidarr and the last few weeks I've been working on and off on a PR. There are some caveats, but generally it seems to work okay.

I hate to see a hard-coded list of names/exts, but it's better than what we don't have today. Could you consider adding .png files to the list and submit an updated PR?

I've been having the same problem adopting Lidarr and the last few weeks I've been working on and off on a PR. There are some caveats, but generally it seems to work okay.

I hate to see a hard-coded list of names/exts, but it's better than what we don't have today. Could you consider adding .png files to the list and submit an updated PR?

Hey there, sure thing, this is a very reasonable suggestion. I didn't want to hardcode things for long, just trying to get this small but meaningful increment merged sooner. I just rebased the PR branch on the latest develop and included this suggestion. I'll poke around a bit to see if someone can kick off a build and publish a test image. Ideally a few more people can test this against their collections so we can cover different environments / OS / scenarios :)

Edit: The feature can be tested with this docker image: https://github.com/linuxserver-labs/prarr/pkgs/container/prarr/171847234?tag=lidarr-extras-for-albums
If someone gets the chance to try it out, I would love to get some feedback :)

I've been having the same problem adopting Lidarr and the last few weeks I've been working on and off on a PR. There are some caveats, but generally it seems to work okay.

I hate to see a hard-coded list of names/exts, but it's better than what we don't have today. Could you consider adding .png files to the list and submit an updated PR?

Hey there, sure thing, this is a very reasonable suggestion. I didn't want to hardcode things for long, just trying to get this small but meaningful increment merged sooner. I just rebased the PR branch on the latest develop and included this suggestion. I'll poke around a bit to see if someone can kick off a build and publish a test image. Ideally a few more people can test this against their collections so we can cover different environments / OS / scenarios :)

Edit: The feature can be tested with this docker image: https://github.com/linuxserver-labs/prarr/pkgs/container/prarr/171847234?tag=lidarr-extras-for-albums If someone gets the chance to try it out, I would love to get some feedback :)

Working perfectly! Thank you so much for working on this.

Here are some more extensions you could add that show up in music folders:

• .acu
• .accurip
• .jpeg (instead of jpg)
• .m3u
• .m3u8
• .md5
• .pdf
• .sfv
• .yaml

I've been having the same problem adopting Lidarr and the last few weeks I've been working on and off on a PR. There are some caveats, but generally it seems to work okay.

I hate to see a hard-coded list of names/exts, but it's better than what we don't have today. Could you consider adding .png files to the list and submit an updated PR?

Hey there, sure thing, this is a very reasonable suggestion. I didn't want to hardcode things for long, just trying to get this small but meaningful increment merged sooner. I just rebased the PR branch on the latest develop and included this suggestion. I'll poke around a bit to see if someone can kick off a build and publish a test image. Ideally a few more people can test this against their collections so we can cover different environments / OS / scenarios :)
Edit: The feature can be tested with this docker image: https://github.com/linuxserver-labs/prarr/pkgs/container/prarr/171847234?tag=lidarr-extras-for-albums If someone gets the chance to try it out, I would love to get some feedback :)

Working perfectly! Thank you so much for working on this.

Here are some more extensions you could add that show up in music folders:
...

A quick update on the supported extensions. Qstick suggested, that the configuration for per-track extras can be reused here. The list of defaults will be rather short, but at least the setting will be on by default.

I've been having the same problem adopting Lidarr and the last few weeks I've been working on and off on a PR. There are some caveats, but generally it seems to work okay.

I hate to see a hard-coded list of names/exts, but it's better than what we don't have today. Could you consider adding .png files to the list and submit an updated PR?

Hey there, sure thing, this is a very reasonable suggestion. I didn't want to hardcode things for long, just trying to get this small but meaningful increment merged sooner. I just rebased the PR branch on the latest develop and included this suggestion. I'll poke around a bit to see if someone can kick off a build and publish a test image. Ideally a few more people can test this against their collections so we can cover different environments / OS / scenarios :)
Edit: The feature can be tested with this docker image: https://github.com/linuxserver-labs/prarr/pkgs/container/prarr/171847234?tag=lidarr-extras-for-albums If someone gets the chance to try it out, I would love to get some feedback :)

Working perfectly! Thank you so much for working on this.
Here are some more extensions you could add that show up in music folders:
...

A quick update on the supported extensions. Qstick suggested, that the configuration for per-track extras can be reused here. The list of defaults will be rather short, but at least the setting will be on by default.

please check if it is working for multi-cd releases. It does not seem like so :(

Please use Discord for support/questions.

sorry @bakerboy448 I was talking specifically to that release.

sorry @bakerboy448 I was talking specifically to that release.

Can you post some details? Artist, album, logs, dir structure - extra files location (which directory) etc. As long as there is a dedicated Artist subfolder in the multitrack naming configuration, this should work for multi-CD releases as well.
I did a quick test and the extra files inside the CD1 / CD2 directory were preserved. But the files in the root album dir are gone. Did you experience the same or was it not working at all for you?

If you want, you can also share them privately with me. Pop up on Discord and join the lidarr-testing channel if you can :)

sorry @bakerboy448 I was talking specifically to that release.

Can you post some details? Artist, album, logs, dir structure - extra files location (which directory) etc. As long as there is a dedicated Artist subfolder in the multitrack naming configuration, this should work for multi-CD releases as well. I did a quick test and the extra files inside the CD1 / CD2 directory were preserved. But the files in the root album dir are gone. Did you experience the same or was it not working at all for you?

If you want, you can also share them privately with me. Pop up on Discord and join the lidarr-testing channel if you can :)

can't seem to find lidarr-testing in servarr discord :(

but in an occasion such as this:
https://i.imgur.com/gIN1Doo.png

CD01 is imported with all extra files, but CD02 is not :/
EDIT: sometimes it will import from CD02 but not from CD01

sorry @bakerboy448 I was talking specifically to that release.

Can you post some details? Artist, album, logs, dir structure - extra files location (which directory) etc. As long as there is a dedicated Artist subfolder in the multitrack naming configuration, this should work for multi-CD releases as well. I did a quick test and the extra files inside the CD1 / CD2 directory were preserved. But the files in the root album dir are gone. Did you experience the same or was it not working at all for you?
If you want, you can also share them privately with me. Pop up on Discord and join the lidarr-testing channel if you can :)

can't seem to find lidarr-testing in servarr discord :(

but in an occasion such as this: https://i.imgur.com/gIN1Doo.png

CD01 is imported with all extra files, but CD02 is not :/ EDIT: sometimes it will import from CD02 but not from CD01

There was a problem indeed, and multi-CD albums as well as a few other common dir layouts had to be handled explicitly.
The new build can be tested with this image: https://github.com/linuxserver-labs/prarr/pkgs/container/prarr/208635980?tag=lidarr-extras-for-albums-2.3.1.4170