1242 - Autosync - Playlist/Track/Album Names Truncated

[nynaevelan]

Ok:

I have tried and tried and I cannot get a 100% sync when the device is syncing incremental syncs the first time around. Here are the results of my last two tests, and there was nothing changed between any of the syncs so there should be no differences. Devs, if nothing has changed with the programming for syncronization for non-ipods, this leads me to believe this has never worked correctly. And to be honest with you, I have never spent this much time investigating a sync, so who knows when the problems started or they have been like this all along, but I would like to have them corrected.



The ones in red are the ones that did not sync correctly the last two times, as you can see I have more tracks on the device then should be and I have the options set to delete those tracks not on the autosync list except for the audiobooks section, which only has 1 track in it and that is on the autosync list.

If you want to look at my db, a copy has been uploaded to here, this issue is not going to go away so I would appreciate someone helping me with this.

EDIT: This is why I have more files on the Zen then what is on the autosync list, MM is putting gibberish files on my player:



Nyn

[jiri]

Now back to the DeviceTracks table. I have several questions:

1. Can a developer tell me why this table is not being cleared out if the device is no longer in the Devices table?
2. What other tables within the DB has junk in it that is no longer relevant or correctly linked?
3. What is the purpose of the Maintain DB option if it is not cleaning out this useless junk? And yes I run this process on a weekly basis but I still end up with phenomenon's that no one else seems to encounter. Is it something I am doing or is MM incapable of handling a db in a way that I need it?

1. Thanks, this is just a small bug, a missing trigger. It will be fixed.
2. There shouldn't be any.
3. It's mainly there for checking DB integrity. Anyway, as I wrote, leaving a garbage there was simply an oversight. In any case, it shouldn't be reason to be worried, it doesn't influence the overall DB integrity.

EDIT: This is why I have more files on the Zen then what is on the autosync list, MM is putting gibberish files on my player:

This explains a lot, since the filenames are missing extensions, MM doesn't even try to automatically remove them, since it doesn't handle unknown filenames. Question is, why does this happen. I'm quite sure, that MM doesn't cause the problem, I don't see where would it cut filenames. In order to be sure, you might try to generate a debug log when such corrupted files are created on your device - the debug log would confirm, whether correct filenames were sent from MM.

Jiri

[nynaevelan]

This explains a lot, since the filenames are missing extensions, MM doesn't even try to automatically remove them, since it doesn't handle unknown filenames. Question is, why does this happen. I'm quite sure, that MM doesn't cause the problem, I don't see where would it cut filenames. In order to be sure, you might try to generate a debug log when such corrupted files are created on your device - the debug log would confirm, whether correct filenames were sent from MM.

Jiri

I've tried generating debug logs but since the sync is "successful" the debug log does not reveal any useful information. But I will try it again, as soon as I finish the process of trying to rebuild a 3.0 database that is a copy of the 3.1 db to see if I can get any successful syncs the first time around in 3.0. As for MM causing the problem or not, MM is the only program that has been writing or using the device since I started these tests, so MM IS the cause. Before I started my tests, I formatted the device, so there was nothing on it prior to the tests, and as I stated nothing has touched it during these tests. And these tests were conducted one right after the other, so there was no lag time between them either. And because of the tempermental nature of the Zen, I have not opened any programs that would be querying the device while I am running the tests.

Nyn

[jiri]

Sure, the filenames were created while syncing by MM. However, as I wrote, I'm quite sure, that MM doesn't cause cutting of filenames, I don't see how would it do so and also other users would probably have similar issues. I'd expect that something might be wrong with underlying layers using during sync, like WMDM, device drivers, or so. Anyway, a sucessful sync log would confirm whether MM really sends correct filenames.

Jiri

[nynaevelan]

Sure, the filenames were created while syncing by MM. However, as I wrote, I'm quite sure, that MM doesn't cause cutting of filenames, I don't see how would it do so and also other users would probably have similar issues. I'd expect that something might be wrong with underlying layers using during sync, like WMDM, device drivers, or so. Anyway, a sucessful sync log would confirm whether MM really sends correct filenames.

Jiri

These files are only identifiable when viewing them through a file browser such as Windows Explorer, how many people will view their player in WE? I only happened to look there because I wanted to get a count of the tracks in the folders to match what MM says are on the player. And as I stated earlier I only noticed this problem because tracks are missing from my playlists. My player(s) are large enough that I am never concerned about how many files are on the player or if there is other files on the player. If not for the playlist problem I would most likely never have noticed this problem, and if truth be told I could care less about the file problem. However, I spend a significant amount of time and effort creating my playlists, I WANT them to sync as I have built them. And I want to only have to sync them once for each session. MM is my preferred music program but if it cannot handle this, then it is time I seriously consider finding a program that can. I do not want to have to keep going back and forth with Winamp just to get my player to sync.

[jiri]

Ok, but this topic was originally started as Playlist name truncation, which would probably really be noticed by many other users in case this was an issue often occuring in MM (which seems to be your case).

I'd certainly like to help as much as possible and fix it in MM in case there's anything to fix. However, at this moment I don't see what else could I do about it. In case you capture anything interesting in a debug log, I'll definitely look into it.

Jiri

[nynaevelan]

Jiri:

I have uploaded the sync logs for both of my Zen players along with an Excel spreadsheet stating what was occurring when the syncs were processing. The worksheet has two spreadsheets, one for each player. There are 3 sync logs for the Zen 8 and 2 for the X-Fi. The X-Fi is the one that has the most tracks/playlists as well as the most syncing problems and of course that is the one that is my main player.

Also, I apologize for my anger earlier I have been working on this for 3 straight days and I am burned out trying to get this resolved because I would like to have my player back up and running by next Tuesday. You can download them from here.

Nyn

[jiri]

I don't see anything related to that truncated filenames you mentioned. What I meant was, that it would be interesting to try to get such a corrupted filename created on the device and when this happen, send me the related debug log, so that I could check out how did it happen.

As for the issues you mentioned about these logs:
1. Freeze of sync - according to the log, it occured during copy of album art, somewhere in WMDM layer, i.e. out of reach of MM. I'd recommend to try another PC, there seems to be to many strange things going on here. For example, there are apparently debug messages from other app than MM in the debug log, which doesn't normally happen (i.e. you probably use a debug version of some app).
2. Re-upload of 3 tracks - it's hard to analyze just from the logs, without the devices, DB, etc. However, it seems that there would be some reasonable explanation for this, like changed metadata (playcount?) or something like that.

Jiri

[nynaevelan]

I don't see anything related to that truncated filenames you mentioned.

Forgive my cyncism, but I am not surprised by this answer.

What I meant was, that it would be interesting to try to get such a corrupted filename created on the device and when this happen, send me the related debug log, so that I could check out how did it happen.

I do not know how to accomplish this since I do not know when the files are added and corrupted. The only thing I would be able to do is use the debug viewer each time I sync. I understand the logs are large and I am sure cumbersome to analyze but I do not want to minimize them to a few tracks in order to avoid "removing" the track(s)/playlists that could be causing the problems. Since both Zen's share some files and playlists, if it is not MM, it has to be one or the other of them.

As for the issues you mentioned about these logs:
1. Freeze of sync - according to the log, it occured during copy of album art, somewhere in WMDM layer, i.e. out of reach of MM. I'd recommend to try another PC, there seems to be to many strange things going on here. For example, there are apparently debug messages from other app than MM in the debug log, which doesn't normally happen (i.e. you probably use a debug version of some app).

This shoud not be happening since I do not have the album art option selected. And the only debug program I am running is the Debug Viewer. But I will try it from another pc, but I hope you realize that this causes problems also since the files are "different" on each pc.

2. Re-upload of 3 tracks - it's hard to analyze just from the logs, without the devices, DB, etc. However, it seems that there would be some reasonable explanation for this, like changed metadata (playcount?) or something like that.

Jiri

That would seem reasonable since I am playing before, during and after syncs. I am not so concerned about re-uploading the tracks, I am more concerned with the ones that are not being deleted.

Nyn

[nynaevelan]

Jiri:

I just uploaded another debug file here. This was the second sync on my Zen 32gb device on my laptop. The first was ok because that was the initial sync. There was nothing else running except the background programs, and MM was not playing any files or anything else. It locked up when copying track 90 of 252. Between the first and second sync attempts I changed some tracks within playlists, and there were some differences in playcounts so the 252 tracks should have been re-uploaded. The device was locked on track 90 for over 2 hours, I finally terminated the process as you'll see in the log.

I do not know how to give you the list of programs running in the background but I know the list includes Network Magic, Mcafe Antivirus, Norton Ghost and the Epson Artisan 700 Print driver.

EDIT: I was looking at the log and I do not understand why it has this line:

Code: Select all

00012684	1816.56689453	[3796] DeviceIcons: Loading Device Icon: C:\ProgramData\Pure Networks\Network Magic\VenResources\NM5.5\CISCO_SYSTEMS\WRT160NV2\64.png 

Nyn

[jiri]

I do not know how to accomplish this since I do not know when the files are added and corrupted. The only thing I would be able to do is use the debug viewer each time I sync. I understand the logs are large and I am sure cumbersome to analyze but I do not want to minimize them to a few tracks in order to avoid "removing" the track(s)/playlists that could be causing the problems. Since both Zen's share some files and playlists, if it is not MM, it has to be one or the other of them.

If you find that there's newly created a file that has cut filename (i.e. 'Artist - Ti' instead of 'Artist - Title.mp3') and have all the previous sync activity captured in a debug log, then no matter how huge it will be, it will be easy to check out, whether it was created by MM (as I wrote, seems to be very unlikely to me) or some underlying process.

The latest log you sent is interesting - the last error code received by MM is E_WPD_DEVICE_IS_HUNG, which speaks for itself. However, that's all I can tell, no more info about reasons...

I was looking at the log and I do not understand why it has this line

Exactly, that's what I meant. This is one of the messages from another process than MM. It can be some system process, probably something related to synchronization, USB, or anything like this. This definitely doesn't happen normally, applications don't write debug messages, unless in debug versions. So, I'm slightly worried about this.

Jiri

[nynaevelan]

I was looking at the log and I do not understand why it has this line

Exactly, that's what I meant. This is one of the messages from another process than MM. It can be some system process, probably something related to synchronization, USB, or anything like this. This definitely doesn't happen normally, applications don't write debug messages, unless in debug versions. So, I'm slightly worried about this.

Jiri

Since this happened on a dfferent machine than what I normally use, how do I determine where the problem lies?? Both machines are Vista, and have both Mcafee and Network Magic on them. Other than that, how do I determine other similarities?? Or more importantly, find the culprit?

[jiri]

Well, it's hard to give any good advice when something strange happens on a PC. You can try to use PID (which was 3796 in the log message above) and find which process it belongs to. You can find it in Task Manager, in case you enable PID column in process list. However, I'm not sure if it will help much, since it probably will be some system process and we won't find out which DLL does it. Also, I'm not saying the debug message necessarily means anything wrong. It's just surprising and quite uncommon to see it on a normally running PC.

Jiri

[nynaevelan]

Well, it's hard to give any good advice when something strange happens on a PC. You can try to use PID (which was 3796 in the log message above) and find which process it belongs to. You can find it in Task Manager, in case you enable PID column in process list. However, I'm not sure if it will help much, since it probably will be some system process and we won't find out which DLL does it. Also, I'm not saying the debug message necessarily means anything wrong. It's just surprising and quite uncommon to see it on a normally running PC.

Jiri

I do not have a PID3796 running on the laptop now so I am not sure what it was, the only thing I can think of is if the network went down on the wireless device on the laptop and Network Magic recovered it. But like you said, why is it showing up in the debug log? This instance has not occured on the desktop, but the desktop also does not run NM wirelessly. After doing some 'net searches I found out how to disable the drive watch feature of the Roxio software which could be causing problems, I have also disabled some startup features using msconfig and so far I have had 2 successful syncs on my X-Fi, I am in the process of testing syncs on my Zen 8. Hopefully one of these processes has either fixed the problem or minimized it's occurrence, because I do not know about you but I am getting tired of working on this. I'll let you know.

However, using your instructions above I did find out this one, which is still appearing in the logs is caused by Mcafee so I am off to look at the settings for the Data Backup feature of that software:

Code: Select all

00017180	1083.38378906	[1812] Event caught from the drive watcher : C:\Windows\Temp\mce00126\-------------- 	

Whatever happened to the time when I could just turn on a 'puter and not have to worry about problems, like that time ever existed...

Nyn

[jiri]

Whatever happened to the time when I could just turn on a 'puter and not have to worry about problems, like that time ever existed...

Yes, I guess everyone knows this feeling. At this moment, my HTPC (running Vista Media Center) doesn't record TV. It used to, I don't know about any significant change, but it doesn't anymore.

Jiri