-
-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lidarr not moving extra files #484
Comments
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:
These files would import correctly. However.. If files were named like this:
Only the matched track 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 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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
also import timed lyrics and renaming them to match the track file names would be very useful. ".lrc" |
Does anyone have a working solution to this yet as this has been an ongoing issues since I started using Lidarr. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Finally got everything else working great and thought I was going crazy here, glad to see I'm not. +1 Gentoo Linux 4.19 Nothing in debug logs even considering any of the file types I've entered. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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? |
The main development team is split across 4 apps: Lidarr, Prowlarr, Radarr, Readarr. 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? |
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? |
I'd be down to look into this issue, but I would need some mentoring/some pointers to get started. (: |
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 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 |
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. |
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. If you want, you can also share them privately with me. Pop up on Discord and join the |
can't seem to find but in an occasion such as this: CD01 is imported with all extra files, but CD02 is not :/ |
There was a problem indeed, and multi-CD albums as well as a few other common dir layouts had to be handled explicitly. |
No matter what I try Lidarr refuses to move extra files (.nfo, .jpg, etc.) I have it setup in the settings and have tried with and without a period before the extension to no avail.
Is anyone else having this issue?
It would be nice if there was an option to move any files with these extension (even if it is as is and not renamed).
The only thing that I can thing is it isn't moving them, because after renaming the music files the remaining extra files aren't a "Matching exacta file".
AB#452
The text was updated successfully, but these errors were encountered: