Syncing, Ejecting Question
 

I want to know a little more about this and if some things can be faster. Upon syncing....it shows everything it is doing to the iPod...Ratings, Playcounts, Writing new Database...blah blah blah.

Upon Ejecting...it shows everything it is doing to the iPod.

Some things are the same. For example, a new database is written when you sync. Upon ejecting, a new database is also written. Is this redundant behavior? Wouldn't the database written while ejecting be identical to the one that was written when you synced? I don't know if there are other operations like this but I just don't see their purpose. I guess if you connect and disconnect your iPod without syncing.....I dunno. I just need clarification on this please. And if I'm correct in my assumptions, can the redundant eject operations be removed to improve speed. THANKYOU

There is a lot of redundancy here, you are right. It's always the same database that gets written.

It was even worse times ago....

Actually, it shouldn't be written until eject. That is what iTunes does. If you quit or crash before Eject - bang, all changes lost. The approach here was (I guess) to make it a bit safer: Even if it crashes or hangs, the status after the last sync is preserved on the iPod. But it takes time...

Yeah, I always wondered about that myself. The database shouldn't have to be written twice. Once is sufficient.

Best way would be to keep a dirty flag, and write only at eject if this is set. But I doubt that I can find all spots where it must be set in this messy code....

Hmm...well why is it Writing a New database when I sync? Is this a setting I have put on?

No, that's done always. No way to change this easily without shuffling around a bunch of code...

Okay, so I'm trying to figure this out... if the database is written at the end of every transfer (sync, autofill, drag-and-drop, etc.)--which it is--then under what other circumstances would it ever have to be written at eject?

At eject the SPLs are updated, and maybe a smart sync is performed. After that, the DB has to be written.

Abu - I think you're saying there's a possibility that some changes need to be written so the final db write is a "failsafe"?

I asked a question on this topic in the past ... but could the SPL update on eject be skipped or otherwise optional?

I typically connect - sync - eject which means typically, for my use case, there's no need for the second db write on eject.

The other way round would be easier: Only writing at eject, not after sync. Would that help, too?

That would be _THE_ solution. Everyone safely ejects his/her iPod at the end, right? So it's only needed that DB gets written at this phase and not at other phases. imho

(PS: the SPL update at eject should stay, that's friggin handy)

I think that'd be ideal. Especially now that, even if eject on quit is turned off, the DB is still written when Winamp is closed. So there's really no reason to write the DB after a sync if it's just going to get written again, anyway. Unless Winamp crashes, of course... but Winamp tends to be pretty stable in my experience.

Ok, so I'll try to change it that way.

PS: If Winamp crashes, it's usually ml_ipod's fault ;)

I have not been so lucky with Winamp. It crashes on mewhich can cause problems on my iPod also. After I sync to the iPod, I have been doing an eject from the systray. When I try to eject from ml_ipod, it tells me it can't eject the device. Please make sure that this change is optional!

If it says it can't eject, that's no big deal: At that point, the DB is already correctly written. Always use the eject button!

Ok, 2.04p25 is ready.
To revert to the old behaviour, you have to add
writeAtEjectOnly=0
to the global winamp.ini.

BTW: I found no less than 24 places in the code where the DB was written :) Now it's only one.

Also, the transfer dialog is much better now, it shows remaining time, and the progress bar is more accurate for the total time....

Tried it out....much better. I like this behavior much more. Thankyou Abu.

Is the "remaining time" estimation any better now? Before, it was pretty accurate up until it started transferring videos. Then it would tell me there was 50 seconds left, even though it would still take another ten minutes to transfer all the videos... :p

Yes, it should be much better now. It used to assume that all songs take equal time to transfer :( Now I take the filesize into consideration. So it should give you accurate figures even with videos.