Lidarr not moving extra files #335

Author

Owner

@Qstick commented on GitHub (Sep 23, 2018):

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

@Qstick commented on GitHub (Sep 23, 2018): Seems this is happening because the files cannot be matched to tracks. So this is a bug.

deekerman commented

Author

Owner

@ghost commented on GitHub (Jan 15, 2019):

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

@ghost commented on GitHub (Jan 15, 2019): Got the same issue. Tried .jpg, *.jpeg, jpeg and none seem to work.

deekerman commented

Author

Owner

@Qstick commented on GitHub (Mar 3, 2019):

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

@Qstick commented on GitHub (Mar 3, 2019): Note: Currently Lidarr only moves extra files if they have same name. This is troublesome for music and needs to be changed.

deekerman commented

2026-02-20 01:00:31 -05:00

Author

Owner

@hikaricore commented on GitHub (Mar 20, 2019):

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?

@hikaricore commented on GitHub (Mar 20, 2019): 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?

deekerman commented

Author

Owner

@ta264 commented on GitHub (Mar 20, 2019):

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.

@ta264 commented on GitHub (Mar 20, 2019): 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.

deekerman commented

2026-02-20 01:00:31 -05:00

Author

Owner

@hikaricore commented on GitHub (Mar 20, 2019):

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!

@hikaricore commented on GitHub (Mar 20, 2019): 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!

deekerman commented

Author

Owner

@ta264 commented on GitHub (Mar 20, 2019):

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.

@ta264 commented on GitHub (Mar 20, 2019): 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.

deekerman commented

Author

Owner

@hikaricore commented on GitHub (Jul 1, 2019):

Any news on this? I'm basically importing everything manually at this point to avoid extra files from being purged.

@hikaricore commented on GitHub (Jul 1, 2019): Any news on this? I'm basically importing everything manually at this point to avoid extra files from being purged.

deekerman commented

Author

Owner

@RandomNinjaAtk commented on GitHub (Jul 5, 2019):

+1

@RandomNinjaAtk commented on GitHub (Jul 5, 2019): +1

deekerman commented

2026-02-20 01:00:33 -05:00

Author

Owner

@PnoT commented on GitHub (Jul 11, 2019):

same

@PnoT commented on GitHub (Jul 11, 2019): same

deekerman commented

Author

Owner

@RandomNinjaAtk commented on GitHub (Dec 27, 2019):

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

@RandomNinjaAtk commented on GitHub (Dec 27, 2019): also import timed lyrics and renaming them to match the track file names would be very useful. ".lrc"

deekerman commented

2026-02-20 01:00:33 -05:00

Author

Owner

@RandomNinjaAtk commented on GitHub (Feb 8, 2020):

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.

@RandomNinjaAtk commented on GitHub (Feb 8, 2020): Example track and lyric file naming: ![image](https://user-images.githubusercontent.com/8386416/74087046-d0444780-4a56-11ea-9200-58990044bc56.png) 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.

deekerman commented

2026-02-20 01:00:34 -05:00

Author

Owner

@PnoT commented on GitHub (Feb 10, 2020):

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

@PnoT commented on GitHub (Feb 10, 2020): Does anyone have a working solution to this yet as this has been an ongoing issues since I started using Lidarr.

deekerman commented

2026-02-20 01:00:34 -05:00

Author

Owner

@mprachar commented on GitHub (Mar 5, 2020):

+1 I came to request this as a feature when renaming/organizing files from the artist page - I didn't realize it wasn't working on regular import either. IMO, if Lidarr would grab files that are in the same directory as the album tracks it wouldn't have to do the filename matching at all.

@mprachar commented on GitHub (Mar 5, 2020): +1 I came to request this as a feature when renaming/organizing files from the artist page - I didn't realize it wasn't working on regular import either. IMO, if Lidarr would grab files that are in the same directory as the album tracks it wouldn't have to do the filename matching at all.

deekerman commented

2026-02-20 01:00:34 -05:00

Author

Owner

@ghost commented on GitHub (Apr 10, 2020):

yep I just started using Lidarr and noticed this straight away.
So you download an album and it already has files like album.nfo, cover.jpg, discart.jpg, folder.jpg .... but Lidarr just completely ignores them during import, even when adding something like .nfo,.jpg.png etc to the move leftover files parameter.

@ghost commented on GitHub (Apr 10, 2020): yep I just started using Lidarr and noticed this straight away. So you download an album and it already has files like album.nfo, cover.jpg, discart.jpg, folder.jpg .... but Lidarr just completely ignores them during import, even when adding something like .nfo,.jpg.png etc to the move leftover files parameter.

deekerman commented

Author

Owner

@cwaddilove commented on GitHub (Aug 27, 2020):

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.

@cwaddilove commented on GitHub (Aug 27, 2020): 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.

deekerman commented

Author

Owner

@aniqueta commented on GitHub (Nov 8, 2020):

Has anyone figured out a workaround? It seems this is a low priority to fix, but what makes this particularly annoying is the extra files are deleted instead of moved to trash or kept behind to manually move them. Thanks.

@aniqueta commented on GitHub (Nov 8, 2020): Has anyone figured out a workaround? It seems this is a low priority to fix, but what makes this particularly annoying is the extra files are deleted instead of moved to trash or kept behind to manually move them. Thanks.

deekerman commented

Author

Owner

@skahtee commented on GitHub (Nov 13, 2020):

+1
My biggest issue with not importing extra files is missing important .cue files, rendering a single-file album image unmanageable.

Version
0.7.2.1878
Mono Version
5.20.1.34

@skahtee commented on GitHub (Nov 13, 2020): +1 My biggest issue with not importing extra files is missing important .cue files, rendering a single-file album image unmanageable. Version 0.7.2.1878 Mono Version 5.20.1.34

deekerman commented

2026-02-20 01:00:36 -05:00

Author

Owner

@cwaddilove commented on GitHub (Jun 2, 2021):

Tried moving to Windows even but still no luck.

Version
3.2.1.5070
.NET
Yes (5.0.5)

@cwaddilove commented on GitHub (Jun 2, 2021): Tried moving to Windows even but still no luck. Version 3.2.1.5070 .NET Yes (5.0.5)

deekerman commented

Author

Owner

@CypherMK commented on GitHub (Nov 4, 2021):

It still does not work. It's one of the most important features that need to work to make Lidarr relevant. Otherwise I still have to do it all manually. So any news on this?

@CypherMK commented on GitHub (Nov 4, 2021): It still does not work. It's one of the most important features that need to work to make Lidarr relevant. Otherwise I still have to do it all manually. So any news on this?

deekerman commented

2026-02-20 01:00:36 -05:00

Author

Owner

@cwaddilove commented on GitHub (Nov 4, 2021):

It still does not work. It's one of the most important features that need to work to make Lidarr relevant. Otherwise I still have to do it all manually. So any news on this?

Your post is the most news yet lol. I still use to keep track but I stopped using for file management. I'm months behind on new music just due to the manual processing time required. I'd pay someone to fix this.

@cwaddilove commented on GitHub (Nov 4, 2021): > It still does not work. It's one of the most important features that need to work to make Lidarr relevant. Otherwise I still have to do it all manually. So any news on this? Your post is the most news yet lol. I still use to keep track but I stopped using for file management. I'm months behind on new music just due to the manual processing time required. I'd pay someone to fix this.

deekerman commented

2026-02-20 01:00:36 -05:00

Author

Owner

@ta264 commented on GitHub (Nov 4, 2021):

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

@ta264 commented on GitHub (Nov 4, 2021): Don't expect anything soon. And please, comments asking for updates or stating it's critical functionality are not helpful.

deekerman commented

Author

Owner

@gold007eye commented on GitHub (Dec 17, 2021):

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?

@gold007eye commented on GitHub (Dec 17, 2021): 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?

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Dec 17, 2021):

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.

@bakerboy448 commented on GitHub (Dec 17, 2021): > 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.

deekerman commented

Author

Owner

@gold007eye commented on GitHub (Dec 17, 2021):

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).

@gold007eye commented on GitHub (Dec 17, 2021): 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).

deekerman commented

Author

Owner

@aniqueta commented on GitHub (Dec 18, 2021):

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.

@aniqueta commented on GitHub (Dec 18, 2021): 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.

deekerman commented

Author

Owner

@aniqueta commented on GitHub (May 10, 2022):

@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.

@aniqueta commented on GitHub (May 10, 2022): @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.

deekerman commented

Author

Owner

@ShadXo commented on GitHub (Aug 21, 2022):

I would love to get this fixed.

@ShadXo commented on GitHub (Aug 21, 2022): I would love to get this fixed.

deekerman commented

2026-02-20 01:00:38 -05:00

Author

Owner

@Span24 commented on GitHub (Aug 24, 2022):

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?

@Span24 commented on GitHub (Aug 24, 2022): 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?

deekerman commented

Author

Owner

@ta264 commented on GitHub (Aug 25, 2022):

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.

@ta264 commented on GitHub (Aug 25, 2022): > 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.

deekerman commented

2026-02-20 01:00:38 -05:00

Author

Owner

@Span24 commented on GitHub (Aug 25, 2022):

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.

@Span24 commented on GitHub (Aug 25, 2022): > > 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.

deekerman commented

2026-02-20 01:00:39 -05:00

Author

Owner

@aniqueta commented on GitHub (Aug 26, 2022):

@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.

@aniqueta commented on GitHub (Aug 26, 2022): @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.

deekerman commented

2026-02-20 01:00:39 -05:00

Author

Owner

@NaruZosa commented on GitHub (Feb 3, 2023):

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.

@NaruZosa commented on GitHub (Feb 3, 2023): 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.

deekerman commented

2026-02-20 01:00:39 -05:00

Author

Owner

@Kaduo commented on GitHub (Jul 4, 2023):

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

@Kaduo commented on GitHub (Jul 4, 2023): I'd be down to look into this issue, but I would need some mentoring/some pointers to get started. (:

deekerman commented

Author

Owner

@Visne commented on GitHub (Oct 1, 2023):

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?

@Visne commented on GitHub (Oct 1, 2023): > 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?

deekerman commented

Author

Owner

@Span24 commented on GitHub (Oct 2, 2023):

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!

@Span24 commented on GitHub (Oct 2, 2023): > > 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!

deekerman commented

Author

Owner

@causalmask commented on GitHub (Dec 9, 2023):

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. :(

@causalmask commented on GitHub (Dec 9, 2023): 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. :(

deekerman commented

2026-02-20 01:00:41 -05:00

Author

Owner

@tty418 commented on GitHub (Dec 17, 2023):

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.

@tty418 commented on GitHub (Dec 17, 2023): 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.

deekerman commented

Author

Owner

@sydlexius commented on GitHub (Jan 4, 2024):

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?

@sydlexius commented on GitHub (Jan 4, 2024): > 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?

deekerman commented

2026-02-20 01:00:41 -05:00

Author

Owner

@tty418 commented on GitHub (Jan 27, 2024):

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 :)

@tty418 commented on GitHub (Jan 27, 2024): > > 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 :)

deekerman commented

2026-02-20 01:00:41 -05:00

Author

Owner

@oldsweatyman commented on GitHub (Jan 29, 2024):

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

@oldsweatyman commented on GitHub (Jan 29, 2024): > > > 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

deekerman commented

2026-02-20 01:00:42 -05:00

Author

Owner

@tty418 commented on GitHub (Feb 7, 2024):

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.

@tty418 commented on GitHub (Feb 7, 2024): > > > > 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.

deekerman commented

2026-02-20 01:00:42 -05:00

Author

Owner

@rodrigorodrigo commented on GitHub (Feb 12, 2024):

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 :(

@rodrigorodrigo commented on GitHub (Feb 12, 2024): > > > > > 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 :(

deekerman commented

2026-02-20 01:00:43 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Feb 12, 2024):

Please use Discord for support/questions.

@bakerboy448 commented on GitHub (Feb 12, 2024): Please use [Discord](http://lidarr.audio/discord) for support/questions.

deekerman commented

2026-02-20 01:00:43 -05:00

Author

Owner

@rodrigorodrigo commented on GitHub (Feb 12, 2024):

sorry @bakerboy448 I was talking specifically to that release.

@rodrigorodrigo commented on GitHub (Feb 12, 2024): sorry @bakerboy448 I was talking specifically to that release.

deekerman commented

2026-02-20 01:00:43 -05:00

Author

Owner

@tty418 commented on GitHub (Feb 15, 2024):

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 :)

@tty418 commented on GitHub (Feb 15, 2024): > 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 :)

deekerman commented

2026-02-20 01:00:44 -05:00

Author

Owner

@rodrigorodrigo commented on GitHub (Feb 15, 2024):

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

@rodrigorodrigo commented on GitHub (Feb 15, 2024): > > 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

deekerman commented

2026-02-20 01:00:45 -05:00

Author

Owner

@tty418 commented on GitHub (Apr 25, 2024):

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

@tty418 commented on GitHub (Apr 25, 2024): > > > 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

deekerman commented

2026-02-20 01:00:45 -05:00

Author

Owner

@stusemple commented on GitHub (Dec 15, 2024):

Hi, can I check this has been incorporated into the latest images going forwards?I am using the latest image and still having the issue described above.

@stusemple commented on GitHub (Dec 15, 2024): Hi, can I check this has been incorporated into the latest images going forwards?I am using the latest image and still having the issue described above.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Dec 15, 2024):

For support and inquiries, please use our Discord channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.

This is open thus not merged into nightly/develop/main.

@bakerboy448 commented on GitHub (Dec 15, 2024): For support and inquiries, please use our [Discord](http://lidarr.audio/discord) channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you. This is open thus not merged into nightly/develop/main.

deekerman commented

Author

Owner

@CypherMK commented on GitHub (Dec 28, 2024):

So, is this issue fixed with moving all the files?

@CypherMK commented on GitHub (Dec 28, 2024): So, is this issue fixed with moving all the files?

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Dec 28, 2024):

This issue is open thus not fixed.

The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one active developer contributing to these projects, with none of the contributors working on them full-time. Lidarr and Readarr are not a focus at this time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations.

As a result, the list of tasks to be completed across these projects, along with the various backends and modules, is extensive, while the available time for addressing these tasks is limited.

@bakerboy448 commented on GitHub (Dec 28, 2024): This issue is open thus not fixed. The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one active developer contributing to these projects, with none of the contributors working on them full-time. Lidarr and Readarr are not a focus at this time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations. As a result, the list of tasks to be completed across these projects, along with the various backends and modules, is extensive, while the available time for addressing these tasks is limited.

deekerman commented