Yes, that' the point. New & changed scans doesn't always work as
expected. They are very good programmed but sometimes buggy. So it might
bei s way to improve them instead of using several workarounds..? ;)
frank1969's Pro
slartibartfast wrote:
> New and changed scans don't always do what you expect. A clear and
> rescan should fix it. Alternatively remove that album folder, do a new
> and changed scan then replace the folder and do another new and changed
> scan.
>
> Sent from my Pixel 3a using Tapatalk
Just re
frank1969 wrote:
> yes, this is the workaround I use (moving the folder to antother
> directory (I call it "quarantine" for years, btw) , do another
> new&changed, move the folder back, do once again a "new&changed") - but
> I thought, why always use a workaround if there is a way to fix it? :)
slartibartfast wrote:
> New and changed scans don't always do what you expect. A clear and
> rescan should fix it. Alternatively remove that album folder, do a new
> and changed scan then replace the folder and do another new and changed
> scan.
>
yes, this is the workaround I use (moving the
I've had this happen when I accidentally have a few tracks that have
disk number (1/1). This can happen with my dbpa ripper, when I rerip a
few tracks and forget to clear the disk number box. Those tracks with
stray disk number field get put into a different album, with same name.
*Home:* VBA
frank1969 wrote:
> This is something I watched several times but no I have one case where I
> can reconstruct how it happened:
>
> I have one album in one folder (as usual) in my database.
> No I see, that 2 of the album's tracks have the wrong album-tag. (eg
> Track 3-10 are correctly labelled
This is something I watched several times but no I have one case where I
can reconstruct how it happened:
I have one album in one folder (as usual) in my database.
No I see, that 2 of the album's tracks have the wrong album-tag. (eg
Track 3-10 are correctly labelled as "Album XYZ", Track 01 and
