Write does not seem to complete correctly #10
Comments
|
Could you try to comment out I have seen sporadic problems with the TOC edit phase on my own device, but have never managed to figure out the cause. I suspect that there's some kind of synchronization missing between the track and metadata write. |
|
I thought for a second that might work. It worked the first time I wrote a track without problem or error, but the next track failed. Wiping the disk and starting from scratch with the first track again also failed. First session, first track (success): First session, second track (fail): Second session, first track (failed): A third write of the first track to a clean disk also failed, but is playable on the device. The device did get stuck in the Edit Toc loop, but seemed to break itself out of it about 30 seconds after the |
|
I've narrowed it down. It doesn't appear to be related to TOC. It appears to happening during A successful write: And a failed one: The I wondered if the player is busy and not listening to the serial channel when the command is sent until after Any thoughts of where I could poke around further? |
|
The secure mode stuff is generally temperamental and pretty much anything can cause the player to crash, so I'm afraid I don't have any straightforward ideas. Since some tracks work, the cipher setup is probably correct, so it's likely that this is either a timing or alignment problem. When writing to a blank disc, if you look at the line |
|
Sorry, I managed to miss that you had tried rewriting the same track to a blank disc already. It's unlikely that this is an alignment issue. So a timing issue looks likely. You might try to add the Otherwise it may be necessary to set up Sonicstage somewhere and snoop its USB traffic to see what's happening between the end of track transfer and the track commit. |
|
I tried the One thing that seemed to help was to increase In the end, I'm beginning to wonder if it might just be a faulty player being the reason it's not seeming to respond in a timely manner when committing a track. |
|
#4 reported similar-ish issues related to what appears to be faulty device (Sonicstage couldn't write tracks either). If you can somehow try out Sonicstage that might provide conclusive evidence, but for least pain you'll need a 32-bit Windows XP/Vista/7 installation, so still quite a bit of pain. But there's some good news: I grabbed a Sonicstage USB trace today and found two bugs in how the track title is written. From reading the massively baroque AV/C standards, these commands probably have never served much purpose because they mostly repeat stuff the device should already know, but some firmwares may expect to receive them [1]. I'll try to put together this week a version that fixes these. If that doesn't solve the problem but you can Sonicstage working, a USB capture with your device may be informative. I can send you a working installer if needed. [1] I wouldn't blame the firmware authors if they just assume that the computer sends a fixed sequence in commands. Implementing all of this bloated monstrosity in the 90s would have required a second Minidisc just for the firmware. |
|
Can you try the latest master and see if it improves anything? The original idea turned out to be a red herring, the auxiliary write commands take a different destination address format than the actual write commands and were correct as-is. However, the Note that if the write is interrupted, the device will be left in a random state and usually pretty unhappy about it. It should be fully rebooted before trying again. I'm planning to work on error and interruption handling soon so that |
|
I think you may have it! I've officially written 4 tracks to a disk without error - the most I've been able to write so far. I've also noticed that the required polling to get a Edit: 6 tracks and counting it. I'm going to say that was the problem. Great job, and thank you! Edit 2: Just for note, I wrote a 10 track EP to disk and observed that polling requests did in fact still creep up at times. Nowhere near like it used to. The last track had to poll about ~30 times before getting a response. Not sure if this is expected, or something notable with just my player. Still, considering the current value of I THINK the number of polling requests might have a relationship to the number of tracks written to the disk in some capacity - maybe even just since the last restart/reconnect - but I'm not sure. Just thought it was note worthy. |
|
Good to hear that it's working at least to some degree. I pushed a refactoring commit which shouldn't change any functionality. 30 polling iterations sounds like a lot. There's not much downside to increasing the maximum, but it would be nice to know if there's something else that could be done. Have you tested with multiple discs? |
|
I haven't tested with a second disk since your last update that appears to work without any actual failures. I'll try to write another longer disk later today though and gather some more data on |
|
If you write tracks until the polling slows down, then completely power off the device, then write a new track, does it still poll for a long time? One possibility is that the device runs some housekeeping at each poll. If it doesn't get enough of them, there will be housekeeping tasks stuck in a queue. Sonicstage sends polling requests continuously so housekeeping would always happen, but |
|
Hey, sorry. I did try writing another disk the other day, and I was right back to square one again. I think the difference that made it appear like everything was working after your change is I grabbed a disk I had only tried to write to once the previous day. The other two disks I had been attempting to write to were set aside. Upon further inspection, the two disks I spent the most time writing to appear to be scratched on the top side. I'm not sure if it's the magnetic head scratching the disk or something else going on. Reading doesn't appear to scratch the disk. I can play for hours on old already written disks and they show no signs of scratching. I think your change did make a difference, because I was now able to write to a disk the first or second time without issue where as I wasn't able to write to the two other disks the first time without failure These aren't new disks I'm working with, and truth be told opening up the slider they appear to be quite dusty. I know they were once used in quite a dusty environment before being retired. I'm going to try to clean the remaining disks I have and try again. I have 2 disks that have yet to be written to since being pulled out of storage. Barring that, I may have to obtain some news disks to proceed any further. |
When writing a track, it appears to not finalize the write properly. My NetMD device seems to be waiting for something else from the host that isn't sent.
Everything seems to work up until
New Track: 0, at which point my device flashesEdit, and the applications seems to halt. After several seconds,netmdcliresponds with the rest of the log above, and the device is stuck in write mode withEditon the display. In some cases, if I kill power to the device the track appears to be written and can play but might be corrupt leading to problems with reading when re-staring the device (the longer the device is powerd up, the longer it takes for the device to read the disk when it re-starts) It seems like the device just continues writing garbage afternetmdclikills the connection.If I do manage to successfully write a single track, I can't seem to write subsequent tracks at any point after without erasing the disk.
Device is a MZ-N420D for what it's worth.
The text was updated successfully, but these errors were encountered: