Open SeanArumae opened 4 years ago
Strange. I do look for both .aiff and .aif file extensions, not case sensitive. I don’t know why yours would be being skipped. Is it every .aif file for you, or just some? Is it all operations, or only some specific sequence that cause the skipping? If you can narrow it down that’ll help, but I’ll take a look here with a renamed file. For that copying part all I do is look at file extensions, don’t even look inside the file so shouldn’t be any way for different file contents to matter at this point.
I’m not completely sure yet. I’ll experiment a little more to see if I can narrow it down and figure out what files specifically are being skipped. For the time being it seems that no matter how I run it, the program ALWAYS reports ALL .aiff files copied, and ALWAYS reports ALL .aif files skipped. I’ll let you know if I find out anything more. I have a pretty even mix of both extensions (.aiff and .aif) that have been ripped at different times over the past 15 years or so.
Sean
On Apr 14, 2020, at 11:26 AM, tattwamasi notifications@github.com wrote:
Strange. I do look for both .aiff and .aif file extensions, not case sensitive. I don’t know why yours would be being skipped. Is it every .aif file for you, or just some? Is it all operations, or only some specific sequence that cause the skipping? If you can narrow it down that’ll help, but I’ll take a look here with a renamed file. For that copying part all I do is look at file extensions, don’t even look inside the file so shouldn’t be any way for different file contents to matter at this point.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tattwamasi/TeslaTunes/issues/22#issuecomment-613509457, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFVFR5KVK3GW6EVZB2OWC3RMR6D3ANCNFSM4MHZ3KIA.
I added the .aif check feb 15 2018 and I don’t think I did an “official” release since. So if you aren’t running one of the test versions I’ve linked in some of these issues, I’m betting that could be the issue. Try https://github.com/tattwamasi/TeslaTunes/files/2805553/TeslaTunes_1.2.6-16-g8858973-dirty.zip if you want. That’s from the m3u issue thread here, and I think is the latest version I’ve let out. I do need to release a fresh version with the accumulation of new Apple updates, just to keep the code signing, etc. fresh, but that should work in the meantime if you’d like to give it a shot.
That did the trick! I used the dirty compilation that you sent, re-ran the scan, and all .aif and .aiff files are now found and can be copied over.
Thanks for solving that for me!
Sean
On Apr 14, 2020, at 11:44 AM, tattwamasi notifications@github.com wrote:
I added the .aif check feb 15 2018 and I don’t think I did an “official” release since. So if you aren’t running one of the test versions I’ve linked in some of these issues, I’m betting that could be the issue. Try https://github.com/tattwamasi/TeslaTunes/files/2805553/TeslaTunes_1.2.6-16-g8858973-dirty.zip https://github.com/tattwamasi/TeslaTunes/files/2805553/TeslaTunes_1.2.6-16-g8858973-dirty.zip if you want. That’s from the m3u issue thread here, and I think is the latest version I’ve let out. I do need to release a fresh version with the accumulation of new Apple updates, just to keep the code signing, etc. fresh, but that should work in the meantime if you’d like to give it a shot.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tattwamasi/TeslaTunes/issues/22#issuecomment-613519433, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFVFRYNPTUOWORUVGFN4MLRMSAF7ANCNFSM4MHZ3KIA.
Hello,
I wonder if you could give these screenshots a look. The music scan is working fine after I installed the latest dirty test version you linked to. However, when I go to actually copy/convert, only a fraction of the songs are properly copied over (about 20-25% on average.) I’ve tried it several times with different settings, both playlist only and playlist plus whole folder. When I look inside the newly copied folders, all the songs are listed there with accurately formatted filenames, but the majority of them are 0KB size. And it’s not specific to any file type or even album-by-album. There are several albums where part of the songs were converted and/or copied, but the remainder did not fully copy and are 0KB files. It also appears to be converting some .aif files to flac, but others it keeps as .aif?
For example, look at the second screenshot with the file list. You can see that the album Northern Soul by The Verve properly copied from my iTunes library to this new folder in .aif format. However, just below, the album Urban Hymns, also by The Verve, has some files fully converted to FLAC and some copied as 0KB size original .aif files. Both these albums were ripped at the same time with the same settings from CDs as .aif files, so there is no reason I can think of that they should be handled any differently by the program. I also can’t figure out why so many of the songs copied have no content (0KB size).
Any ideas, or anything you can suggest for me to try to further troubleshoot this?
Thank you so much for your dedicated work on this project! We Tesla owners very much appreciate you and would be willing to support your work with a donation!
Sean
On Apr 14, 2020, at 11:59 AM, Sean Arumae sean.arumae@gmx.us wrote:
That did the trick! I used the dirty compilation that you sent, re-ran the scan, and all .aif and .aiff files are now found and can be copied over.
Thanks for solving that for me!
Sean
On Apr 14, 2020, at 11:44 AM, tattwamasi <notifications@github.com mailto:notifications@github.com> wrote:
I added the .aif check feb 15 2018 and I don’t think I did an “official” release since. So if you aren’t running one of the test versions I’ve linked in some of these issues, I’m betting that could be the issue. Try https://github.com/tattwamasi/TeslaTunes/files/2805553/TeslaTunes_1.2.6-16-g8858973-dirty.zip https://github.com/tattwamasi/TeslaTunes/files/2805553/TeslaTunes_1.2.6-16-g8858973-dirty.zip if you want. That’s from the m3u issue thread here, and I think is the latest version I’ve let out. I do need to release a fresh version with the accumulation of new Apple updates, just to keep the code signing, etc. fresh, but that should work in the meantime if you’d like to give it a shot.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tattwamasi/TeslaTunes/issues/22#issuecomment-613519433, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFVFRYNPTUOWORUVGFN4MLRMSAF7ANCNFSM4MHZ3KIA.
Sorry, I keep coming back to this and thinking about it, but don't have an easy answer for you. The screenshots didn't show up, so you may have already tried this, but based on other people's experiences with various fobs, I do suggest trying a different USB device, or even better verify it to your own hard drive/ssd first.
Not sure if you are seeing extremely slow speeds, or if there is something happening that is erroring or hanging to give you all the 0 sized files. The app is multithreaded and can have multiple copies happening, so not necessarily odd to see multiple temporarily 0 sized files but they shouldn't stay that way.
Thanks for your patient response. I am trying once more to attach the two screenshots—they are important to illustrate what I mean.
I’m seeing this mysterious problem crop up BEFORE I even attempt to use a USB. I’m simply having the software build the Music folder on my own computer’s hard drive (which is a fast SSD).
It’s not slow speeds or hangs—in fact the program runs blazing fast on my computer. In fact it finished processing my entire 86GB library containing over 13,000 songs in just about a half hour! The problem is that it just stops and reports being finished—with over 3/4 of the songs copied as 0 size files. it doesn’t report them as skipped, it just says (for example) 2,694 files copied/converted out of 13,179 files to copy/convert out of an original 13,834 files scanned (when I run it for my whole music library).
The 0 size files doe show up initially as temporary containers or space-holders; the problem is that the software finishes its work and completes without having ever filled in any data for these songs.
Thanks for your patient help troubleshooting. Please let me know if it would be more appropriate to open an issue through Github.
Sean
On Apr 17, 2020, at 4:43 PM, tattwamasi notifications@github.com wrote:
Sorry, I keep coming back to this and thinking about it, but don't have an easy answer for you. The screenshots didn't show up, so you may have already tried this, but based on other people's experiences with various fobs, I do suggest trying a different USB device, or even better verify it to your own hard drive/ssd first.
Not sure if you are seeing extremely slow speeds, or if there is something happening that is erroring or hanging to give you all the 0 sized files. The app is multithreaded and can have multiple copies happening, so not necessarily odd to see multiple temporarily 0 sized files but they shouldn't stay that way.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tattwamasi/TeslaTunes/issues/22#issuecomment-615454882, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFVFRZ3JULEQCUDVWNCB4LRNC5OTANCNFSM4MHZ3KIA.
For a particular file, does it always fail, or is it random? If there is a particular file, I can take a look at it. Still not seeing screenshots but don’t think it matters. Just trying to figure out if it’s repeatable in a way I can see to help with.
Yes, having run the program in multiple different ways (selecting different settings), several times now with my iTunes library, it does appear to be leaving the same songs as 0 size files each time. I cannot figure out what triggers it, but yes, it’s the same files that seem to fail.
What’s the best way to send example files to you? Most of them are .aiff uncompressed files that are 10-40 MB and thus too large to email…
Thanks, Sean
On Apr 19, 2020, at 9:33 PM, tattwamasi notifications@github.com wrote:
For a particular file, does it always fail, or is it random? If there is a particular file, I can take a look at it. Still not seeing screenshots but don’t think it matters. Just trying to figure out if it’s repeatable in a way I can see to help with.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tattwamasi/TeslaTunes/issues/22#issuecomment-616263610, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFVFR72USCCQ5VFSSEMUMDRNORAHANCNFSM4MHZ3KIA.
Well, your luck with screenshots aside, I'd say attach one here :)
I'm replying inside Github this time, rather than just through email. Maybe that's why the attachments weren't going through the first couple times. Attaching those pesky screenshots, plus two example audio files that fail and copy over as 0 size files. So far, it's mostly .m4a, .mp3, and .aiff files that are gumming up the works. (Can't attach any of the .aiff files--they're over the 10mb limit that Github imposes, so here are an m4a and mp3 that are failing...)
Cool, will check these two files out to see if they do the same for me. Thanks.
Yes
On Apr 20, 2020, at 4:02 PM, tattwamasi notifications@github.com wrote:
Cool, so those two files both will do the 0 size thing?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tattwamasi/TeslaTunes/issues/22#issuecomment-616778006, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFVFR73WEZNVV3ZTY7NMLTRNSS43ANCNFSM4MHZ3KIA.
Just a quick bump. Did you happen to replicate the error or have any thoughts on why the files are not processing through the program?
No chance to look at them yet, sorry. Still flagged and on the list though, far from bottom but not at top. Hope I can look this weekend if nothing else.
Thanks, no worries, get to it when you can. I really appreciate you even taking a second look. I’m experimenting myself in the meantime.
On Apr 24, 2020, at 11:09 AM, tattwamasi notifications@github.com wrote:
No chance to look at them yet, sorry. Still flagged and on the list though, far from bottom but not at top. Hope I can look this weekend if nothing else.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tattwamasi/TeslaTunes/issues/22#issuecomment-619069666, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFVFR2ZJJHGWFKBPVKPIYTROGTT5ANCNFSM4MHZ3KIA.
I'm not sure why it copies .AIF and .AIFF files over, without converting them, since they aren't playable by the Tesla (at least by my 2023 Model Y Long-Range). Also, it's not copying the AlbumArtist tag to the Artist, even though I checked that checkbox.
When trying to scan my playlists for copy/conversion over to my USB thumbdrive, I am seeing that the program will successfully copy over .AIFF (uncompressed CD rip) files. However, it is listing .AIF files under the "Extensions Skipped". I was under the impression that .aiff and .aif are really the same file format, just one uses the Windows standard 3-character extension, and the 4-character extension is more commonly used by MacOS. I am a Mac user. Any idea what might be going on? See attached window screenshot.