MediaMonkey forum

Finally I'm back home and the net will let me upload the fix, sorry bout that

New Version

' 04-10-08 Version 2.3.2
' Fixed ini filename missing on first run

MoDementia wrote:Finally I'm back home and the net will let me upload the fix, sorry bout that

New Version

' 04-10-08 Version 2.3.2
' Fixed ini filename missing on first run

Is this another beta or a final release?

Nyn

Now I'm getting this error:



Nyn

Beta still I guess

That line is the start of the year check but I have never seen that error
I don't think any year data is null or not a number will have to help you find the actual entry that is generating the error

Had a quick look on the net for the error and looks like a general database error
maybe restart MM or PC and try again?

Tried both and it still doing the same thing, it is getting stuck on the same file. A copy of the db (mm.db), networked db (mm.net.db) and file (Prince - Baby I'm A Star.mp3) are in the usual place if you want to try it. Maybe I am doing something wrong, here are the steps I am using:

1. Exported a complete database to networked drive.
2. Opened DEISync and selected Sync Network Database
3. Navigated to network db and hit ok

Did I miss a step?

Nyn

New Version (Still Beta)

' 06-10-08 Version 2.3.3
' Fixed Year(s) and CDbl Fields old logic

Did I mention that I couldn't remeber which parts I had rechecked and which ones I hadn't when I decided to change the script direction/logic sorry bout that

[EDIT] Same version Number but removes DEISyncLog Table when exporting database.

[EDIT AGAIN] Same version number but without the typo

I am now getting the following error, I am assuming because there is a track in the original db that is not in the networked db because it worked fine after I did a complete db export and the track it stopped on is one I just added to the db. I know you stated you weren't clear what you were going to do about new tracks yet but is there a way around the error until a decision is made?



Nyn

I think I see,
It reports new tracks in the network db but not new tracks in the local db

Ok, now that it works as long as there are no new tracks in either db, I'm having some cosmetic issues.

1. Can you move the artist/title to the beginning of the rows, all the info is running off the screen and you have to scroll to the right to see what the track is before deciding on which changes to accept.
2. Also can you make the fields smaller, they are so large you have to scroll to the right? I have a 24" screen and even with the panel maximized, there is still not much room to see everything on one line.

Other than that the changes which are in the original db are showing up correctly in the change log. But if one was to implement using this option, what would be the best course of action to avoid any problems?

Also, can this option be used if the tracks on the networked pc is networked back to the original location of the tracks and/or if there are duplicate copies of the tracks physically located on the networked pc?

Ok:

I've played with it some more and I have a few requests:

1. Can you add either an option to globally accept/reject changes or add an option sheet for which database should be the default db to keep?
2. Can you add the total tracks and playlists to the bottom of the Confirmation sheet?

Nyn

New Version (Still Beta)

' 07-10-08 Version 2.3.4
' More Year Fixes
' Fixed New Tracks and deleted tracks
' Removed duplicate confirmation lines

Just fixes some errors and hopefully will make it easier to analyse if its doing the right thing

Before I reply below a couple of things need clarifying I think

The new option should be thought of in the same way the stable version works.
i.e.
Export Sync Database From Network Database
Import Sync Database to Local Database
Then
Export Sync Database From Local Database
Import Sync Database to Network Database

This option eliminates the Export Sync Database step by connecting directly to the network database.
and what is new in this option is eliminating the second export/import.

Most of the problems with the beta version is that the Import is bidirectional
i.e. You are not just importing the changes from the network database to the local database
It is trying to do 2 import/exports in 1 go.

If you want to have a closer look at the data the confirmation screen is being generated from check out the DEISyncLog Table in both databases.

nynaevelan wrote:1. Can you move the artist/title to the beginning of the rows, all the info is running off the screen and you have to scroll to the right to see what the track is before deciding on which changes to accept.

Not yet Depending on what fields are changed the current format works ok sometimes but not so great other times.
I did play around with wrapping the data in a set field width but that also had it's problems.
Hopefully I can get it to a point where you can trust the recommended changes and it will just be a glance to see if anything stands out (then scroll to the right) to check it.

nynaevelan wrote:2. Also can you make the fields smaller, they are so large you have to scroll to the right? I have a 24" screen and even with the panel maximized, there is still not much room to see everything on one line.

See Above. I'm sure there is room for improvement at some point but I would like to wait until the comfimation screen is stable and 99% trustworthy before doing anything

nynaevelan wrote:Other than that the changes which are in the original db are showing up correctly in the change log. But if one was to implement using this option, what would be the best course of action to avoid any problems?

Unlike the stable version Export/Import Sync database you have a choice whether to accept the changes or not
Technically the confirmation screen should be as valid as the Export Sync Database option

nynaevelan wrote:Also, can this option be used if the tracks on the networked pc is networked back to the original location of the tracks and/or if there are duplicate copies of the tracks physically located on the networked pc?

Can't understand this one enough to reply
If the stable version Export/Import Sync database works with your current set up it will also work

nynaevelan wrote:1. Can you add either an option to globally accept/reject changes or add an option sheet for which database should be the default db to keep?

Globally reject = Cancel?
Globally accept = OK?
I dont want it to be a unidirectional option like the current stable version, I belive that the default Local/Network choices it makes should be correct.
Its more a case of making sure they are correct (by modifying the script) than just globally overwriting it's logic.

nynaevelan wrote:2. Can you add the total tracks and playlists to the bottom of the Confirmation sheet?

At some point

PS @Nyn: Could you remove the error images from the previous posts once they are corrected? the server they are on is quite slow

MoDementia wrote:

nynaevelan wrote:Also, can this option be used if the tracks on the networked pc is networked back to the original location of the tracks and/or if there are duplicate copies of the tracks physically located on the networked pc?

Can't understand this one enough to reply
If the stable version Export/Import Sync database works with your current set up it will also work

If the tracks are mapped on a network drive will it work the same for a db that have the tracks physically connected to the computer.

MoDementia wrote:

nynaevelan wrote:1. Can you add either an option to globally accept/reject changes or add an option sheet for which database should be the default db to keep?

Globally reject = Cancel?
Globally accept = OK?
I dont want it to be a unidirectional option like the current stable version, I belive that the default Local/Network choices it makes should be correct.
Its more a case of making sure they are correct (by modifying the script) than just globally overwriting it's logic.

Ok, I get the global cancel but as the script is now the network is the default for all the options. If for some reason the user would rather have the network overwrite the values of the local db, then you have to change the values for all the changed fields. If there are alot of changes, this could become tedious.

MoDementia wrote:PS @Nyn: Could you remove the error images from the previous posts once they are corrected? the server they are on is quite slow

What do you mean, I am not having any lags in performance....

Nyn

nynaevelan wrote:If the tracks are mapped on a network drive will it work the same for a db that have the tracks physically connected to the computer.

It's comparing against Song IDs not paths so yes it will work

nynaevelan wrote:Ok, I get the global cancel but as the script is now the network is the default for all the options. If for some reason the user would rather have the network overwrite the values of the local db, then you have to change the values for all the changed fields. If there are alot of changes, this could become tedious.

I mentioned in the first post that is is important to choose the best PC to run it from.
i.e. If most of the changes show up as network DB changes then you should run the script from the network PC then all the changes will be local. (and the tags will be written)
If the script is suggesting the wrong DB to update then the logic needs to be looked at.
i.e there should not be the need to mass change the suggestions decided by the script.

nynaevelan wrote:What do you mean, I am not having any lags in performance....

It's this image that is taking ages to download, looks like a weird link

I don't know what's wrong with it but I removed it, let me know if you still have problems.

Nyn

Yeah the server is having some difficulties, or the connection from Australia is