X940BT "forgets" iPod VR catalog after a week

[nosaJ-11C7]

Hello everyone,

 

I have a strange problem that I was hoping that somebody might be familiar with   I have an X920BT upgraded to X940BT using the official 2013 map update.  I have a 160 GB 4th gen iPod classic with about 8,500 songs.  The headunit builds the VR catalog fine and iPod voice commands work for around a week, then suddenly it seems to forget all the song/artist/album VR information.  Any iPod voice command causes it to respond with "what was that?" or "i didn't understand you".  The workaround is simple, but annoying - resynchronize the iPod with iTunes, then the headunit will rebuld the VR catalog properly...for another week.  So far I haven't been able to figure out a particular event or action which causes the VR information to disappear.  Anyone else have this problem?  The original X920BT software had the same problem, and in typical pioneer fashion, all the bugs from the X920BT software are still there in the X940BT   The same issue occurs regardless of whether the nag screen bypass is used, and toggling the VR cataloging option in the menu doesn't help either.  If anyone knows a better solution I would appreciate it!  Thanks!

[nosaJ-11C7]

I used testmode to investigate the issue further.  I found that the VR database is stored in \USER\RW\VBT\EN\EN_US.  In this directory, I noticed a file FINISH.db.  I discovered that if I delete this file, it causes the system to rebuild the VR catalog properly.  So I can carry an SD card in the car and delete this file when the problem occurs instead of resynching the iPod.  This is better, but I'm also trying to find a nicer solution.  By deleting FINISH.db and letting the system build a new VR catalog, I was able to compare a working copy of the VR database files to a non-working copy - the contents of the files are very different, so it seems the database is corrupted by some unknown software bug.  As far as I can tell, the VR processing is done via third party software called VoiceBox, which is \USER\PRG0\APL\VBT\VBTEngine.exe.  So the question is, how does VoiceBox know to write the VR database to \USER\RW\VBT\EN\EN_US?  There is a file VoiceBox.cfg, but the paths listed in this file don't exist on the system, so I don't think it's actually used.  Instead, one of the Pioneer processes must pass the location to VBTEngine.exe.  So I went to work with a Hex editor searching all of the files in USER\PRG0\APL for any of the path or file strings, but unfortunately I cannot seem to find them in any file.  My thought was to seperate the VR cataloging and recognition databases into two seperate folders - the system would catalog to one location (which it would invariably corrupt), and then I could keep a second, untouched copy of the database in another location for VR usage.  Whenever I resynch the iPod I would need to copy this folder, but I figure that's better than the current behavior. 

 

The other option would be to have some automated process delete FINISH.db on every startup.  Unfortunately I don't see any existing scripts in the file system which could be adapted for this purpose.

 

Hmm, maybe after some time I can think of another solution...

 

 

[nosaJ-11C7]

I think it will be too hard for me to reverse engineer the VBTEngine.exe interface.  I don't have IDA and it seems to be very expensive software so I decided to focus my efforts on forcing the VR database rebuild.  I downloaded Condi's HackMode and spent some time understanding how it works by looking over the scripts and the forum posts.  I realized that I can use a similar idea to accomplish my objective:

 

Replace Av.exe with Mortscript, just like in Condi's HackMode, except modify Av.mscr to delete FINISH.db and then run the original Av.exe.  This way the VR database is rebuilt every boot.

 

As an alternate idea, I can keep a good copy of the VR database in a different folder and use the script to overwrite the working copy every boot.  This would be faster but I'll have to see if the database corruption is still avoided...

[nosaJ-11C7]

Ok, after some tweaking, I got my script running.  My active software is in PRG0, so I put the MortScript files from Condi's HackMode into \USER\PRG1\APL: Av.exe, commctr1.dll, coredl1.dll, killproc.exe, MortScript.exe, toolhel1.dll.  Then I created the following Av.mscr in the same folder:

# VR database rebuilder script

ErrorLevel("warn")

Delete("\NAND\RW\VBT\EN\EN_US\FINISH.db")

Run("\NAND\PRG0\APL\Av.exe")

Exit

Finally, I added PRG.FLG into \USER.  The VR database rebuilds every time now.

 

I tried my alternate idea of copying a known working copy of the VR database every boot, but it didn't work - the VR stopped working immediately.  I had assumed VBTEngine.exe was launched by Av.exe, but perhaps it is launched by something else (HMIManager.exe?) and therefore it doesn't like me replacing the files while it's running.

 

I also learned some interesting things in this process - I wondered why Condi used the second PRG folder for HackMode instead of just renaming Av.exe in the same folder.  So I tried just renaming Av.exe to Av1.exe and having the script call it, but Av1.exe would hang during boot.  So I put (Pioneer's) Av.exe in a subfolder, but the same result - the system hangs during boot.  So apparently (Pioneer's) Av.exe must exist with that name in either PRG0 or PRG1 - it won't work from any other directory or any other name.

 

Another interesting thing I stumbed upon is the infamous "There is no applicable program" message during boot.  When I put Mortscript in PRG1, this message started appearing.  I thought about why simply changing from PRG0 to PRG1 would make any difference, and I realized that the OS images in PRG1 were older than PRG0.  So basically I was booting an older Windows image (PRG1), and then trying to run Pioneer's Av.exe which was designed for a newer image (PRG0).  I suspect Condi never saw this because by coincidence he had the same software in both PRG0 and PRG1, or at least very similar.  In my case I had the AVIC-X940 firmware in PRG0 and AVIC-X920 firmware in PRG1.  The solution was simple - delete PRG1 and then make a copy of PRG0 and name it PRG1 - this fixed the problem.  Now the OS image is the same in both PRG0 and PRG1 and only the application (Av.exe) is different.

 

As a side project I thought about the bug where the XM station logos don't apppear sometimes after boot.  I thought that maybe Av.exe is loading before the P920XM tuner has a chance to gather all the station data.  To test this theory, I added a 20 second delay to the script to give the XM tuner plenty of time to gather everything.  Unfortunately this made no difference, so I guess it is not a race condition with Av.exe.