Windows Powershell overwhelming flashdrive RRS feed

  • Question

  • I have a powershell script that I use to copy my ITunes library (700 folders, 5,700 files, 23 GB) and generate playlists to a flash drive for use in my car audio system.   My car requires that the flash drive be formatted FAT32.  If I copy the library and playlists "manually" via Windows Explorer Copy and Paste, the audio system uses the playlists and all is well.

     If I run a powershell script using "Copy-Item" or "RoboCopy" everything appears to be fine (Winmerge folder compares indicate that source and target folders are Identical), but audio system is unable to use the playlists.  It claims they are empty although that is not the case (as verified via notepad).

    I tried setting the Robocopy multi-tasking level to 1 but the problem persists.  I have the manual workaround, but it would be much easier to start a script and walk away.  Are there any folder copy alternatives that would mimic Copy - Paste?  Any suggestions would be appreciated.

    Monday, March 24, 2014 10:38 PM


  • This isn't a scripting question. A file copy is a file copy. It may be that you have a shell extension installed on your system that does something "extra" when copying the files to the USB so it works when you connect it in the car, but as I said, there is no way for us to know what might be different in your specific case. Sorry that we can't be of more help.

    -- Bill Stewart [Bill_Stewart]

    Wednesday, March 26, 2014 2:14 PM

All replies

  • Suspect that the drive is too big for FAT32.

    Copy is copy.  It doesn't matter if it is PowerShell DOS or wugnutz.  They all use the copy API.  RoboCopy will use multiple threads but it still just copies bits from  a to b.

    Older devices cannot read beyond a certain size on FAT drives.  Try using a smaller drive to see if it works.  Just move a few files and one playlist.  YOu can also just reformat the 23G and place only a few files on it for a test.

    I suspect you test with Explorer succeeded due to the order of the files which may have initially placed the playlists at the beginning of the drive.


    Monday, March 24, 2014 11:03 PM
  • The audio system is from a 2012 Toyota so it is not terribly old, but obviously is still primitive (the FAT32 requirement as well as file and folder limits - I am within the stated limits on files and folders).  Unfortunately the drive I'm using is 64 GB (the smallest I have that will hold everything) and I use a 3rd party product EASUS Partition Master to format the drive.  I believe that the audio system can read all the iTunes library files since the Songs menu comes up with all of the songs in the library and can play them all (at least all I've tried). I've tried songs from artists at both ends of the alphabet in the assumption that files are copied in alphabetical order as reported in the robocopy log.

    I have a 2GB drive that I can use to test a subset and if that works I will use the same subset on the larger drive.  Once I have done that I will report back.  Most likely tomorrow.

    Monday, March 24, 2014 11:38 PM
  • No -- I know what the problem is and you can test it very easily.  The playlists need to be in Unicode.  Open a playlist in notepad from the drive and check to be sure it is in Unicode and not ansi. 


    Tuesday, March 25, 2014 12:14 AM
  • I copied (Copy - Paste) one album and a single entry playlist to a 2gb thumb drive for testing and everything worked as it should.  I deleted the copied folders and used robocopy with the following parameters /mir /xo /mt:1 to copy the same album and playlist to the thumb drive.  The playlist problem returned.  I did this before I read the last post and sure enough the playlist was in ANSI.  I tried saving it as Unicode and tried again but the playlist problem remained.  The playlists are in .PLS format which is the only way I could get the audio system to use my playlists after much trial and error.  I assume that .pls format gets around the Unicode issue.

    I'm certain the problem lies downstream from Windows as as "Winmerge" reports that the source and destination files are identical and none of the copy operations report any errors.  I can consistently create and correct the problem by changing the method I use to copy the data to the thumb drive.  There must be a difference no matter how subtle.  Any other ideas?

    Tuesday, March 25, 2014 2:46 PM
  • As I posted earlier. This is not a scripting issue. 

    Windows playlists are in WPL format. What is PLS? It is not Windows media.

    This is what a Windows playlist looks like:

    <?wpl version="1.0"?>
            <meta name="Generator" content="Microsoft Windows Media Player -- 12.0.9200.16420"/>
            <meta name="IsNetworkFeed" content="FALSE"/>
            <meta name="ItemCount" content="0"/>
            <meta name="IsFavorite"/>
            <meta name="ContentPartnerListID"/>
            <meta name="ContentPartnerNameType"/>
            <meta name="ContentPartnerName"/>
            <meta name="Subtitle"/>
                <media src="..\01 Pulo do Gato.wma"/>
                <media src="..\02 À Gandáia das Ondas-Beppo.wma"/>
                <media src="..\03 À Primeira Vista.wma"/>
                <media src="..\04 O Choro de Juliana.wma"/>
                <media src="..\05 Rhythms.wma"/>
                <media src="..\06 Song for Badi.wma"/>
                <media src="..\07 Bate-Coxa.wma"/>
                <media src="..\08 Feixe.wma"/>
                <media src="..\09 Quase Um Funk P&apos;ra Badi-Vírus.wma"/>
                <media src="..\10 Laser.wma"/>
                <media src="..\11 Ica.wma"/>
                <media src="..\12 Pau Brasil.wma"/>
                <media src="..\13 Moods.wma"/>
                <media src="..\14 Carta a l&apos;Exili.wma"/>


    Tuesday, March 25, 2014 3:04 PM
  • I'm aware of the various playlist formats.  I tried several of them when I was first trying to get this stuff to work 2 years ago.  The issue is not which playlist format I'm using but that different copy methods are yielding different results.  While this may not be a scripting issue it is most certainly a powershell issue as a powershell cmdlet causes this problem.  I don't recall you saying that this was not a scripting issue in your previous posts!  If you're saying I should pursue this somewhere else that's fine.  Point me in the right direction! 

    Tuesday, March 25, 2014 3:31 PM
  • Sorry if I didn't post that this is not really a scripting issue.  I also cannot debate this because I do not own an old Toyota.  I am pretty sure that the 32Gb USB is not compatible with the Toyota system.  You would have to contact the manufacturer to prove that.

    If Windows cannot copy a file to a foreign device in a format it understands then the device is not compatible with Windows.

    Since we do not have your script, USB and Toyota there is not much that anyone can do.  You will need to pursue this on your own. 

    Try a smaller USB.  Use the CMD copy command.  Does it work?


    Tuesday, March 25, 2014 3:41 PM
  •  It is a 2012 Toyota not old by any means.  As I indicated earlier I used a 2GB flash drive with the same result.  The device is not foreign as it is formatted by windows and the files created by windows.  The audio system reads the files...nothing more; it shouldn't be able to tell what code created the files it is reading!  I would buy your arguments if the playlists never work but they DO WHENEVER I USE COPY - PASTE in Explorer.  I will try the copy command.       
    Tuesday, March 25, 2014 4:30 PM
  • I tried xcopy to copy the all of the iTunes library in one fell swoop and that resulted in the same problem.  The copy command doesn't appear to handle sub folders so I didn't try that.  Any other ideas?
    Tuesday, March 25, 2014 10:23 PM
  • There must be something else going on - the shell must be doing something that a straight file copy isn't doing. Unfortunately there is no way for us to know what that could be. However what jrv said earlier was correct: File copying all uses the same underlying Windows APIs, no matter whether the Explorer shell is doing it or someone else. But what's for sure is that you don't have a scripting problem. Unfortunately we can't help you with your problem because we can't reproduce it.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, March 25, 2014 10:29 PM
  • I say it is an incompatibility with the USB stick.  I have seen similar things before on large drives.


    Wednesday, March 26, 2014 1:22 AM
  • Well, whatever it is, we can't reproduce it, so there's really nothing we can do.

    -- Bill Stewart [Bill_Stewart]

    Wednesday, March 26, 2014 2:28 AM
  • The only difference I can come up with is that RoboCopy Copy-Item etc use multiple threads to speed up the copies.  Apparently explorer does not or doesn't to the extent of the others.  I was hoping to discover some way to reduce the amount of parallel processing, but I guess there is no such trick.  I was hoping to avoid it, but I may try adding logic to the script to run through the folders copying them one at a time.  I'm kind of surprised that this wasn't suggested as a possible solution.  

    This was my first time using this forum and will certainly be my last. Not because there was no solution... I have no problem with that.  I take exception to the arrogant tone of some of the posts.  They didn't contribute anything useful to the discussion!

    Wednesday, March 26, 2014 1:24 PM
  • Now you are just making up nice stories.  Copy-Item, cop and xcopy do not use multiple threads.  THe issue is that you need to ask the vendor

    I scanned the web for issues with large USB drives and with playlists.  There are many issues.  This is not a scripting issue.  We cannot help you in this forum.  Please contact the vendor for assistance.


    Wednesday, March 26, 2014 1:50 PM
  • Please educate me on the means that
    Wednesday, March 26, 2014 2:01 PM
  • Robocopy and Copy-Item speed up the process if not through some sort of parallel processing.
    Wednesday, March 26, 2014 2:02 PM
  • This isn't a scripting question. A file copy is a file copy. It may be that you have a shell extension installed on your system that does something "extra" when copying the files to the USB so it works when you connect it in the car, but as I said, there is no way for us to know what might be different in your specific case. Sorry that we can't be of more help.

    -- Bill Stewart [Bill_Stewart]

    Wednesday, March 26, 2014 2:14 PM
  • Please educate me on the means that

    You are not a trained WIndows system engineer or systems programmer.  Threading has nothing to do with how these utilities work.  THe issue is not a scripting issue.  You are just frustrating yourself by hacking at this.

    You issue is about compatibility or configuration.  You need to post in the vendor forum for your device. It is also possible that you have system issues on your PC. PLS is not a Windows playlist extension. 


    Wednesday, March 26, 2014 2:18 PM
  • Actually I was a systems programmer on a different platform for 25 years.
    Wednesday, March 26, 2014 7:04 PM