On Friday, August 19, 2016 at 12:37:01 PM UTC-4, Adrian Sampson wrote: > > Aha, thanks for clarifying! > > No, that should not happen—if it does, it's a bug. There's one exception: > if you `beet ls` while an import is currently happening, or if beets > crashes halfway through, you might see the old paths. >
then that is likely what I'm seeing. so to further clarify, beets temporarily writes the import file location into the database? This would be a durability bug, because if the program crashes, now the DB is basically corrupted ? > > On Aug 19, 2016, at 11:33 AM, [email protected] <javascript:> wrote: > > > > On Thursday, August 18, 2016 at 4:55:19 PM UTC-4, Adrian Sampson wrote: >> >> As always, if you think something’s wrong, please provide instructions we >> can use to reproduce the problem from scratch. >> >> In the mean time, if you have files that have been placed somewhere you >> don’t want them, you can try using `beet move` to have them moved into >> their default locations. >> > > > The basic case of, beets config says the files go in directory /foo. > After an import, beets list shows the path is in /bar. My question is, if > this were to be demonstrated, would this ever be a correct behavior? I'm > not asking you to fix it or diagnose it. Just in the abstract, is that > supposed to happen in some case? thanks for your attention to this > question. > > > >> >> On Aug 18, 2016, at 12:47 PM, [email protected] wrote: >> >> in fact it seems to just be not copying / moving files at all from the >> directory im importing from to the location I've configured. I'm totally >> lost. >> >> beets config: >> >> directory: /mnt/synology_beets_music/ >> library: /mnt/synology_beets_music/library.blb >> import: >> copy: yes >> write: yes >> incremental: yes >> paths: >> default: $albumartist/$album/$track $title >> singleton: Non-Album/$artist/$title >> comp: Various Artists/$album%aunique{}/$track $title >> >> plugins: fetchart chroma discogs scrub edit >> chroma: >> auto: yes >> >> >> command: >> >> beet import /mnt/synology_beets_import/ >> >> it imports some files, and then I see this: >> >> $ beet list American -p >> /mnt/synology_beets_import/American Music Club/San Francisco/01 >> Fearless.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/02 It's Your >> Birthday.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/03 Can You >> Help Me_.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/04 Love >> Doesn't Belong 1.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/05 Wish The >> World Away.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/06 How Many >> Six Packs Does It Take To Screw In A Lightbulb.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/07 Cape >> Canaveral.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/08 Hello >> Amsterdam.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/09 The >> Revolving Door.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/10 In The >> Shadow Of The Valley.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/11 What >> Holds The World Together.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/12 I Broke >> My Promise.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/13 The Thorn >> In My Side Is Gone.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/14 I'll Be >> Gone.m4a >> /mnt/synology_beets_import/American Music Club/San Francisco/15 Fearless >> (Reprise).m4a >> >> I'm lost. Why did it put files *in the library* directly where they are >> sitting in the import location? Why didn't it *copy* them to the *place >> where the files go* ? I'm sure we'll figure out some silly reason >> eventually, but this is just too hard. For this particular album, it >> also decided to drop one of the files from the library, because the name >> didn't match up. Different issue. >> >> >> >> >> >> >> On Thursday, August 18, 2016 at 11:39:01 AM UTC-4, cla...@ >> zzzcomputing.com wrote: >>> >>> Hi - >>> >>> I've been working with beets for some weeks now and while it does a lot >>> of things that are useful, there are many quirks. I'd like to just start >>> sending them to the list and if I have time I can provide more detail as >>> I'm assuming this will be necessary. >>> >>> First one, beets "copy" will not do a copy if the files you are >>> importing happen to be in a deep subfolder of the ultimate target >>> directory, even though the path is wrong and even though the files being >>> accessed *are not* part of the library yet. Beets should raise an error >>> if it can't handle this directory setup and it should never *overwrite* a >>> non-imported file that's not in the correct target location. I >>> understand this probably is interacting poorly with the fact that you can >>> do "beet import" at the existing library directory, however because these >>> files were not present at all in the library beforehand and they are not in >>> the correct library position. >>> >>> assume you set up this: >>> >>> >>> /mnt/my_music/<no files> >>> >>> /mnt/my_music/files_to_import/<all the files I want to import> >>> >>> then set up beets config including: >>> >>> directory: /mnt/my_music/ >>> library: /mnt/my_music/library.blb >>> import: >>> copy: yes >>> write: yes >>> incremental: yes >>> >>> then tell beets to import from that subfolder. >>> >>> beet import /mnt/my_music/files_to_import/ >>> >>> As to why one would do this, I'm working with an NFS-mounted share, and >>> I wanted to keep all the files on the same side of the share so that the >>> "copy" operation would proceed much faster. Of course I could have just >>> made two subdirectories on the share, or used two shares, however the root >>> of the share is where I ultimately want the music to be, and because beets >>> seems to code absolute paths in the library.blb file (another poor >>> practice, as the database file is not portable). >>> >>> So the result is that beet *does not copy* the files, it *overwrites >>> them in place*, thus erasing the tags in the original files which I'd of >>> course like to keep pristine. That is, in the library itself, when I >>> do "beet list -p", the files' permanent location is in the >>> "files_to_import" subfolder which is *not* part of my "paths" >>> configuration, and this is therefore incorrect. >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "beets" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > You received this message because you are subscribed to the Google Groups > "beets" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "beets" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
