2012-08-01, 22:57
Great to hear ViMM is working the same on Mountain Lion, as it does on regular Lion, besides the odd bug you're experiencing of course.
I've completely rewritten the app from scratch for the 0.6 version, that way I could drop a lot of faulty code and add all the new experience i got from making ViMM 0.5.
It's using a totally new and generally more effective way to write the movie paths to the preferences, with your case seeming to be the exception to that.
Luckely, with GREAT thanks to your screenshots, I figured out the problem! apparently ViMM doesn't like to save paths that contain the same folder name.
Or more correctly it does this:
It saves a key with the name "Movies" and the Value "Movie's Path" to your preferences, then it writes a second key with the Name "Movies" and the Value "Another Movie's path", but unfortunately, keys need to be 'unique', so it's just overwriting the previous one.
I'll get right onto fixing that!
Edit: Fixed it by switching the 'key''s and 'value's around, since the path should be unique, and the name definitely shouldn't be, as your case so clearly shows.
It'll be available in the next alpha. ^^
I've completely rewritten the app from scratch for the 0.6 version, that way I could drop a lot of faulty code and add all the new experience i got from making ViMM 0.5.
It's using a totally new and generally more effective way to write the movie paths to the preferences, with your case seeming to be the exception to that.
Luckely, with GREAT thanks to your screenshots, I figured out the problem! apparently ViMM doesn't like to save paths that contain the same folder name.
Or more correctly it does this:
It saves a key with the name "Movies" and the Value "Movie's Path" to your preferences, then it writes a second key with the Name "Movies" and the Value "Another Movie's path", but unfortunately, keys need to be 'unique', so it's just overwriting the previous one.
I'll get right onto fixing that!
Edit: Fixed it by switching the 'key''s and 'value's around, since the path should be unique, and the name definitely shouldn't be, as your case so clearly shows.
It'll be available in the next alpha. ^^