Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[slipknot]

I recently got an ipod and upgraded to 11.1.188.  I ended up creating a virtual handheld pointing to a dir on one of my harddisks to hold the "handheld" (converted from ape to mp3) files.  I synch to a playlist for the ipod.  I then created a new library which then imports the mp3 files which actually synchs to the ipod.  I know there is another new version of MC for me to try, but read on, I've seen the same problem with a 189 install too.

Many times when I switch to the new "ipod" library of mp3 files and import, I end up with hundreds of duplicate track entries, tag for tag is identical.  The pathname and filename's are identical.  I end up deleting both copies of the tracks and reimporting and it's okay for a while.  And then I turn my back and there are hundreds of dups again.  How can MC have duplicate records in the database?  Shouldn't the fully qualified path/filename be a key to the db?

Anyone else have this problem?  I have had this problem since I got the ipod and set up the new virtual handheld and ipod library.  Then tonight, I upgraded my girlfriends MC to the lastest version 11.1.189 and set her up just like mine and presto, we're getting duplicates in the new libaray database, it seems totally random, I cannot find a pattern.

So either I am doing something wrong (hopefully) on hers and my computer, or ... Any ideas?  I can live with this, I just have to be viligant to check for the dups before actually synching to the real ipod from the new library.

Ideas?  Suggestions?

Media Center Registered 11.1.188 -- C:\Program Files\J River\Media Center 11\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
Intel Pentium 4 2997 MHz MMX / Memory: Total - 2095 MB, Free - 1571 MB

Internet Explorer: 7.0.5346.5 / ComCtl32.dll: 5.82.2900 / Shlwapi.dll: 6.0.2900 / Shell32.dll: 6.0.2900 / wnaspi32.dll: 4.71 (0002) , ASPI for Win32         DLL, Copyright © 1989-2002 Adaptec, Inc. / Aspi32.sys: 4.71 (0002)

Ripping /   Drive X: CDWRITERIDE5232           Mode:Normal  Type:Auto  Speed:Max
  Drive Y:   Mode:Normal  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: Yes  Soundfile:   chord.wav

Burning /  Drive X: CDWRITER IDE5232            Addr: 1:0:0  Speed:52  MaxSpeed:52  BurnProof:Yes
  Drive Y: ATAPI    DVD RW             Addr: 1:1:0  Speed:40  MaxSpeed:40  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: No /

[marko]

playlist files getting into the mix? (.m3u and the like)

[slipknot]

playlist files getting into the mix? (.m3u and the like)

Hi Marko, I'm not at home now so I can't check anything.  In the new library, I just import only the dir (and it's subdirectories) which contains the mp3 files which were created from my main library and I only have it import mp3 files although there shouldn't be any other files to import down that directory tree.

If it were a playlist .m3u file, what would I do to solve the problem?   I think I have all file types turned off, other than mp3, but I can check when I get home.

 Thanks for your help.

[slipknot]

There are no playlists involved that I know of or know about.

When I import, only to the directory tree with all my mp3 files, it says there are 23k files in my library.  Like I said before, sometimes it corretly says I have 8400 files after importing, and other times there well over 14k files with thousand of duplicates.  I remove both copies of all dups from the library and reimport.  Sometimes it reimports all the dups and other times it only imports a single copy of the deleted tracks and all is well for a little while.

Since this happens on my computer and on my girlfriends computer, there is either something wrong with MC or more likely something wrong with my setup and I did the same wrong thing when I set her up.

[slipknot]

When importing, the display shows "anaylzing library File: x of 23,945".

Now I know there are only 8400 mp3 files in that directory tree and 1100 directories, so where does the 23,945 number come from?

When the import does right, after importing the library contains 8400 files as expected, when it goes wrong, I have around 14000 tracks in the library which are the duplicates I'm asking about, but never, ever does it have the 23945 tracks which MC seems to think there are.

Where does that 23,945 number come from?

[Alex B]

I don't know why you have dublicate tracks, but you may find an answer to your other question here:

http://yabb.jriver.com/interact/index.php?topic=30238.0

[slipknot]

I don't know why you have dublicate tracks, but you may find an answer to your other question here:

http://yabb.jriver.com/interact/index.php?topic=30238.0

Thanks.  Yes it seems my library is full of duplicates, sometimes 4 dups of the same track.

I have MC set to not exclude previously imported files and fix or remove broken links.

Yes MC keeps all the old tracks around in it's DB.  And since I just recreated this library about week ago (new, not cloned), this behaviour is even more strange.

I created a playlist to find all the dups and manually removed them.  Now time will tell if they start bulding up again.  Thanks for the help and pointing me to the threads that guided me to building those playlists.

[slipknot]

This is unbelievable.

I just switched to my ipod MC library and imported.  And it just keep adding in duplicates.  I can import 2 times in a row and it keeps adding more and more duplicates.

It shows the tracks with the same exact same path and filename.

This is so consistent for me and my girlfriend on her computer, can I really be the only having this problem?

[Matt]

As a test, if you make a new library with library manager and import a small folder twice in a row, do you get dupes then?

Also, does it matter how you import? (Explorer right-click, import tool, in "My Computer" area of MC, etc.)

Thanks.

[slipknot]

As a test, if you make a new library with library manager and import a small folder twice in a row, do you get dupes then?

Also, does it matter how you import? (Explorer right-click, import tool, in "My Computer" area of MC, etc.)

Don't laugh, I didn't know I could import from Explorer until just now...

I've abandoned my idea of two libraries for the dups reason and have decided to go to importing all the virtual handheld mp3 files into my main library, and now I'm getting all the dups in my main library.  So it's something about my j:\ipod directory tree, that is the common factor.

What is the j:\ipod\database.mpl file I keep finding and deleting?  Could that be the cause of the trouble?  Marko had mentioned playlists getting imported somehow the other day, but I thought I had deleted the playlist files but they keep reappearing.  There is also a "Playlist" dir that keeps getting created.

I'm experimenting with adding a BUFFER dir under j:\ipod (j:\ipod\BUFFER) and importing from the BUFFER dir.  I then have the virtual handheld set to j:\ipod only and the directory rule set to include the BUFFER dir.  That means the mpl file and the Playlist dir will be made under j:\ipod, but when I import I'll start at BUFFER making the mpl file and Playlists dir invisible to my import.  I'll try that for a while.

//---------

Nope that didn't work either, I just synched to the virtual handheld and then did an import, and it just imported 8k duplicates.

[slipknot]

Okay, I can duplicate the steps...

I started with only one library, my main library I've had for years.

Using the library manager, I created a new library and pointed it to an empty directory.

I imported j:\ipod\BUFFER.  There are only audio files and directorys in this dir tree.  It imported 8400 files.  I reimported, it found nothing new.  I can import any number of times, and finds nothing new.  So far so good.

I then switch back to my main library and then switch back to the new test library and import.  It imports some 4k new files.  I import again, nothing new.

I switch back to the main library and then switch right back to the test library and import, it imports another 4k duplicates.

This happens EVERY time.

Then if I remove the Virtual Handheld pointing to j:\ipod and clean up all the duplicate mess from the library, then all is well. 

It's the Virtual Handheld causing the trouble.

My girlfriend started having the same duplicate issues on the day I created a virtual handheld for her.

[Alex B]

Oh dear, you are not supposed to import files from the "virtual" handheld.

MC keeps the virtual handheld synchronized with your media library, which is supposed to be elsewhere. You need to have a separate location for the virtual handheld. Otherwise you can just make a playlist named e.g. Handheld for those files.

[slipknot]

Oh dear, you are not supposed to import files from the "virtual" handheld.

MC keeps the virtual handheld synchronized with your media library, which is supposed to be elsewhere. You need to have a separate location for the virtual handheld. Otherwise you can just make a playlist named e.g. Handheld for those files.

If I don't import them somewhere, how could I add them to a playlist?

I originally HAD a separate library for synching with the actual ipod, which imported the files created by the virtual handheld in my main library.

In my main library I use the a playlist and the virtual handheld to manage the mp3 files into a separate directory tree.  Then I created a separate library to manage the actual synching to my ipod, and I had to import the mp3 files in the separate library, else how could MC know about them to copy to the ipod?

[Alex B]

As a test, I just imported the audio files (not the mpl database file) from my virtual handheld folder to a new empty library. Then I made a new virtual handheld to another location and synched the same files with the new handheld. MC copied the files to this other location.

This test library does not have any dublicates. It has the audio files (from the first Handheld folder) in the audio category and the both handhelds contain the files separately.

[slipknot]

Nothing I try seems to work, and I am hoping I am doing something wrong.

These were my steps to setup how I want to handle my ipod.  I want to keep copies of the converted mp3 files, in case I need to reload the ipod since it takes days to convert 60 gig for the ipod.

1.  Create a directory on my hard disk  j:\ipod
2.  Create a playlist called ipod in MC and add all the tracks I'd like to have on my ipod.
3.  Create a virtual handheld, pointing to my ipod playlist and the target is j:\ipod
4.  Synch the virtual handheld which converts all my ape files to mp3 and stores the results in j:\ipod.

5.  Create a new empty library in MC, called ipod.
6.  Switch to that new library and import all files from j:\ipod (only, don't import my main APE files which are in another dir tree)
7.  Plug in my actual ipod and have MC synch from all files in the separate ipod library to the actual ipod.
8.  Eject the ipod.

The ipod is now full.

9.  Switch back to the main library.

Then over time I add more tracks to the ipod playlist and then I synch them to the virtual handheld.

Then I switch to the separate ipod library and import j:\ipod (only) and then plug in the ipod and synch all files to the actual ipod.

But sometimes when I switch to the separate ipod library and import it goes whacky and import duplicate after duplicate, I'll end up with 4-5 copies of the same track in the separate ipod library.

It seem like the the existance of the virtual handheld when I switch to the separate ipod library is screwing things up.  When I switch, I see the "calculating transfer" dialog.

So hopefully you see the flaw in my plan and tell me how to do it right.  This is getting frustrating!

[Alex B]

Rather odd, I can't reproduce that. Though, I don't have a real iPod here. I tried this with two virtual hanhelds.

Do you use the "Sync mode" with your handhelds? I use only the Manual mode.

[slipknot]

I've been using Synch mode.  In the main library synching from the "ipod" playlist.
In the separate library that actually syncs to ipod is using synching from the entire library (since that library only has the mp3 files imported that were created in the other library by the virtual handheld).

I somehow think the problem is the virtual handheld is global across libraries and exists even in the new separate library when I created it in the main library.  And once I switch to the separate library, the "ipod" playlist it's connected to does not exist in this library.

Still, I must be doing something wrong, since others have been using the handheld features for quite a while and I just started trying to use it.

Does anyone have a procedure that works to keeping copies of the converted files (to mp3) and then synching to the acual ipod?  It just can't be this hard.  I don't get offended if someone tells me I am doing something wrong, in fact I want to know what I am doing wrong so I can start doing it right!

[Alex B]

I think you might not need to keep a second library at all.

I just synced my two virtual Handhelds between each other without changing away from my main library.

In my main library I opened the "Drop Files Here" window of my second handheld (in Action Window). Then I browsed to the first handheld in the MC tree (under Drives & Devices), selected all files in the file pane and dragged them to the "Drop Files Here" area. MC removed from the sync list the files that were already in the second handheld and copied the rest of the files correctly.

EDIT

Though, I don't know how the iPod appears in MC. Can you sync it manually like a virtual handheld?

[Alex B]

On second thought, I realize that this would not work well if you would like to keep more mp3 files on the HD than you can copy to the iPod at one time.

[slipknot]

I think you might not need to keep a second library at all.

I just synced my two virtual Handhelds between each other without changing away from my main library.

In my main library I opened the "Drop Files Here" window of my second handheld (in Action Window). Then I browsed to the first handheld in the MC tree (under Drives & Devices), selected all files in the file pane and dragged them to the "Drop Files Here" area. MC removed from the sync list the files that were already in the second handheld and copied the rest of the files correctly.

EDIT

Though, I don't know how the iPod appears in MC. Can you sync it manually like a virtual handheld?

I'm seeing the duplicate problem and I don't even need the ever connect the ipod.  You just need ONE virtual handheld.

I have a virtual handheld pointing to j:\ipod\BUFFER.  It's set to synch to a playlist which contains tracks from my library.  At this time, it's fully synched, there is an mp3 file in j:\ipod\BUFFER for every track in the controlling playlist.

Then click on the Virtual Handheld in Drives and Devices.  Then click ReCheck-Synch and let it do it's thing.

Then take a look at ~d=a, to see everything in your library, and note the track count.

Then click on the Virtual Handheld in Drives and Devices again and click ReCheck-Synch again and then go back to ~d=a and I see thousands more tracks, which increases EVERY time I go through the steps described above.  Every time the track count increases with duplicate after duplicate, 4,5,6 of the same track which will only increase the more times you do these steps.

[Alex B]

Finally, I was able to reproduce this. Somehow something makes MC to think that not all files are already imported if they are in a virtual handheld too. I don't know why. It seems to be a bug. I have excluded everything else than mp3 files in the import dialog. Still MC imports more or less duplicates to the second library on each new import attempt.

I think a possible solution (for now) would be to use the Subst command for making your J:\ipod\BUFFER folder to appear as a new drive letter.

Type the following in the command prompt:

subst X: J:\ipod\BUFFER   and press enter.

This will add a virtual HD, drive "X:". Use a new library and import only from this virtual drive. Check only MP3 in the import options. MC should not get confused anymore because the virtual handheld database points to the J: drive. If the X letter is already reserved you can use some other free letter.

If this works you can save the command line as a text file with Notepad (press enter after the text string so that there is one empty line after the text), rename the file as "xdrive.bat" and place it in the startup programs folder (for all users the location would be: C:\Documents and Settings\All Users\Start Menu\Programs\Startup).

[slipknot]

Finally, I was able to reproduce this. Somehow something makes MC to think that not all files are already imported if they are in a virtual handheld too. I don't know why. It seems to be a bug. I have excluded everything else than mp3 files in the import dialog. Still MC imports more or less duplicates to the second library on each new import attempt.

I think a possible solution (for now) would be to use the Subst command for making your J:\ipod\BUFFER folder to appear as a new drive letter.

Type the following in the command prompt:

subst X: J:\ipod\BUFFER   and press enter.

This will add a virtual HD, drive "X:". Use a new library and import only from this virtual drive. Check only MP3 in the import options. MC should not get confused anymore because the virtual handheld database points to the J: drive. If the X letter is already reserved you can use some other free letter.

If this works you can save the command line as a text file with Notepad (press enter after the text string so that there is one empty line after the text), rename the file as "xdrive.bat" and place it in the startup programs folder (for all users the location would be: C:\Documents and Settings\All Users\Start Menu\Programs\Startup).

I'll certainly give that a try tomorrow, but I don't see the signifigance of the virtual drive, but I'll willing to try anything.  I assume that Jim and Matt and the rest will read this and see that the problem I've been seeing has been duplicated and hopefully get the problem corrected or tell us something we may be doing wrong.

And by the way, in my other life, I'm a C++/Java/Unix application developer, so I'd create that batch file using vi... (gvim).  Forum support is tough, we never know what the experience level is of whom we're talking to.  Thanks for sticking with this and duplicating it.

[Alex B]

I'll certainly give that a try tomorrow, but I don't see the signifigance of the virtual drive, but I'll willing to try anything.  I assume that Jim and Matt and the rest will read this and see that the problem I've been seeing has been duplicated and hopefully get the problem corrected or tell us something we may be doing wrong.

I am almost certain that the workaround will work (it worked for me). MC has no means to see the connection between the apparently separate files that are located in J: and X:.

What I cannot understand is what makes the difference when the libraries switched back and forth. I couldn't reproduce the problem before I switched back to my first library, synced more files with the virtual handheld, switched to the second library and imported again.

And by the way, in my other life, I'm a C++/Java/Unix application developer, so I'd create that batch file using vi... (gvim).  Forum support is tough, we never know what the experience level is of whom we're talking to.  Thanks for sticking with this and duplicating it.

That's true. Though it is always better to try to formulate replies so that all forum users can understand.

[slipknot]

I can reproduce the problem without an ipod and without a seperate library.  I just need to have a virtual handheld set up and switch between normal and the virtual handheld and have it "recheck-synch".

[Alex B]

But do you have the virtual handheld files imported to that library?

[slipknot]

But do you have the virtual handheld files imported to that library?

Yes, it's necessary to have the files created by the virtual handheld imported to they can be added to a smartlist (by filesystem location, not manually adding) to be used as the source of files for the actual synch to the ipod.  But like I said an ipod is not necessary to re-create the problem of duplicacates in the historical part of the library ~d=a.

And the same issue show up if a separate library is created and that virtual library still exists from the main library (as it would) with duplicates.

The problem might go away is we did use 2 libraries, but deleted the virtual handheld whenever swtiching to the alt library (for ipod sync) and the recreating it when returning to the main library for normal MC use.

[Alex B]

I do not have the virtual handheld files imported separately anymore. Library #1 syncs the virtual handheld as before and library #2 has only the files from the virtual drive "X:" for syncing the other handheld.

[slipknot]

I do not have the virtual handheld files imported separately anymore. Library #1 syncs the virtual handheld as before and library #2 has only the files from the virtual drive "X:" for syncing the other handheld.

Then that must mean you have the files from the lib1 virtual handheld imported into lib2.

I still don't get the drive x: thing (I know how to set it up).  Which lib see the actual dir and which lib see the dir as drive x:

[Alex B]

For example,

Library #1 has only this track:
C:\My Music\Artist\Album\01 - Track.ape

I sync it with the virtual handheld. After that the handheld contains this track:
J:\ipod\BUFFER\Artist\Album\01- Track.mp3

Then I create the virtual drive X: with the "subst x: J:\ipod\BUFFER" command and switch to the new empty Library #2.

I import the X: drive contents. After that the Library #2 contains only this track
X:\Artist\Album\01- Track.mp3

I never sync the Library #2 with the virtual handheld, only with the iPod.

[slipknot]

For example,

Library #1 has only this track:
C:\My Music\Artist\Album\01 - Track.ape

I sync it with the virtual handheld. After that the handheld contains this track:
J:\ipod\BUFFER\Artist\Album\01- Track.mp3

Then I create the virtual drive X: with the "subst x: J:\ipod\BUFFER" command and switch to the new empty Library #2.

I import the X: drive contents. After that the Library #2 contains only this track
X:\Artist\Album\01- Track.mp3

I never sync the Library #2 with the virtual handheld, only with the iPod.

Okay, if I understand it correctly, the purpose of the x: drive is to have two ways of ponting to the same file, and those twos ways are enough to convince MC that they are not the same file.  I think it makes sense now, I'll give it a try when I get home tonight.  Thanks for your patience.

Of course the long term solution is an MC code change, or an MC solution to help us maintain two copies of our files, one as lossesss for home use and an mp3 copy for our handheld use.  One solution Matt has suggested would be to have MC maintain a "cache" of handheld converted mp3 files.  Then when the handheld was synched and needed an mp3 file, it would first look into the "cache" for it, before doing a conversion.  He suggested that the cache size would be use configurable.  I'd make mine large enough to have an mp3 copy of every lossless track I own.  Cache management would be transparent to me and I'd have the best of both worlds, lossless for home use and QUICK xfer to my handheld of mp3 files from the cache.

[slipknot]

Alex B - I'm dying to try out your x: drive idea, but I'm involved in putting in a new hard drive tonight and it takes a long time to move all my data around from drive to drive to utilize the new one.  I will try your idea out and let you know.  Thanks again.

[slipknot]

Still have the duplicate problem.

1.  I have 8400 mp3 files in j:\handheld   They ARE NOT imported into my library.
2.  Set up a Virtual Handheld pointing to j:\handheld
3.  Click "Virtual Handheld" in Drives and Devices.
4.  Click "recheck sync" (you may have to let get past "working" the first time)
5.  Check out the file count and contents of ~d=a
6.  Click "Virtual Handheld" again in Drives and Devices.
7.  Click "recheck sync" again.
8.  Notice the THOUSANDS of additional tracks in ~d=a

Repeat steps 6 - 8 and each time there are THOUSANDS more tracks in ~d=a and you'll see the same track repeated over and over again with the same exact tags.

To try the idea Alex B. gave me, I deleted all tracks in ~d=a and deleted the Virtual Handheld.  I then ran this command in a dos window.

subst z: j:\handheld

Then I repeated all of the above using z:\ instead of J:\handheld

and got the same results.  Everytime MC checks the sync of the virtual handheld it adds THOUSANDS more duplicate tracks to the full MC internal library as can be seen with ~d=a.

This is clearly an MC bug and not related to a handheld since I don't need any handheld (other than the virtual one) connected to reproduce the issue.  Outwardly things may seem "normal" but the internal MC library grows forever with each use of the Virtual Handheld.

[Matt]

Handhelds create temporary database entries during their use.  These entries are flushed when the program is closed.  The entries are only visible when explicitly asking the database using the special search token.  This behavior is normal.

As for the other issue, importing the files on a virtual handheld can confuse MC 11 into importing the files multiple times.  We recommend that you simply avoid this scenario.

[slipknot]

Handhelds create temporary database entries during their use.  These entries are flushed when the program is closed.  The entries are only visible when explicitly asking the database using the special search token.  This behavior is normal.

Yes I now see they are flushed on a program restart, I don't normally ever shutdown MC.  Still seems weird to keep adding thousands and thousands of hidden dups but I can live with it, knowing they are flushed on a restart.

As for the other issue, importing the files on a virtual handheld can confuse MC 11 into importing the files multiple times.  We recommend that you simply avoid this scenario.

Agreed.  I only tried using one library when using 2 libraries caused duplicates.

But there is still a dup problem.  I create a virtual handheld in my main library and a playlist to populate it.  It converts my ape files to mp3 as configured.  No problem here.

Then I create a NEW library and import the mp3 files created by the virtual handheld in my  main library so I can actually sync them to my ipod.  This is where the problem duplicate problem develops.  MC import duplicates to the library ~d=m, not just ~d=a.   And every resync it import more and more dups.  I have not tried to see if they go away on an MC restart, but even if they did, they cause issues in the current session for synching to my actual ipod.

[Matt]

Agreed.  I only tried using one library when using 2 libraries caused duplicates.

But there is still a dup problem.  I create a virtual handheld in my main library and a playlist to populate it.  It converts my ape files to mp3 as configured.  No problem here.

Then I create a NEW library and import the mp3 files created by the virtual handheld in my  main library so I can actually sync them to my ipod.  This is where the problem duplicate problem develops.  MC import duplicates to the library ~d=m, not just ~d=a.   And every resync it import more and more dups.  I have not tried to see if they go away on an MC restart, but even if they did, they cause issues in the current session for synching to my actual ipod.

I think I understand.  For now, you'll need to remove the handheld and restart MC before you import into the new library.  Essentially having a handheld pointing to files and importing the same files with MC 11 produces undefined results.  The system simply wasn't designed to handle this.

We are testing a fix for this limitation in the private beta of MC 12.  If it's deemed safe, it may be rolled into MC 11.

Thanks.

[Alex B]

I tested this again. I didn't realise that slipknot meant files that are visible only with the "~d=a" search. (I was actually able to make duplicate files to the main library by importing from the handheld folder.)

Here is what I did now:

1. Make a new empty library
2. Make a smartlist with this rule: [Media Type]=[Audio], named as "Audio Smartlist"
3. Make a smartlist with this rule: ~d=a, named as "DB All"
4. Make a new handheld that uses a folder (D:\HHD...) and syncs with the "Audio Smartlist"
5. Import two ape files from "E:\test\ma\" to the library
6. Go to the handheld and press "Sync Now"
7. Press "Recheck Sync"
8. Go to the "DB All" smartlist
9. Go to the handheld and press "Recheck Sync"
10. Go to the "DB All" smartlist
11. Go to the handheld and press "Recheck Sync"
12. Go to the "DB All" smartlist
13. Go to the handheld and press "Recheck Sync"

After four rechecks the DB All smartlist looks like this:




EDIT

It seems that these duplicates are only temporary. A restart of MC clears them.

[slipknot]

I would think part of the issue is that the "virtual handheld" defination is global to MC and not part of the the named library.

So I set up a virtual handheld in my main library and sync it. 

Then I switch to my alt library and the virtual handheld is still there, which then causes trouble when I import the files created by the virtual handheld while in the main library.

If the virtual device setup became part of the library defination and not global to MC, then when I switch libs, the virtual handheld would no longer be a factor.