OK, so last night I was going through my segues, when I selected three tracks (song - jingle - song) and clicked on Mix Editor. Bang. I received a “Integer overflow” error. I tried to continue. It kept coming back. I then to generate the crash report. Halfway through sending, mAirlist just locked up solid and that was that!
I restarted, loaded the playlist and same thing happened. Tried again, got a “division by zero” error. So, I loaded the same playlist in b1170, and that worked fine. Made my changes and carried on.
Afterwards, trying to recreate the error, the same playlist (modified now in b1170) was ok in b1224.
I’ve tried to recreate the error, deleted the peakdata.db file, and tried the same. No go.
So I exported the playlist as an m3u, re-imported so all timing data was removed. Yes, folks. It goes bang in b1224. I’m sending the bug report now. Same playlist ok in b1170. I think it’s related to a specific track but not sure.
It happens when I click “Mix Editor”, I see the dialog box get drawn then bang. (see attached) I don’t see the waveforms. It could of course be trying to zoom at 100% I guess.
What is odd, is I recreate a playlist just with the 2 files either side of the one that goes bang, Mix Editor behaves. It just goes bang in this playlist!
I will of course try b1227 later and I appreciate the fast response.
The reason why it shows mAirlistxxx in the dialog box is because I renamed it that so I can still use b1170 as my default.
The backtrace pointed definitely to a line where the duration is divided by the number of pixels to determine the requested resolution. If the width is 0 pixels, you get the division by zero error, obviously.
I have changed the code so that the function isn’t even executed when the width is zero (and no data is to be displayed).
Funnily enough, I came across the same error message yesterday when I was working on the voice track editor, but I was in a hurry so I just dismissed the dialog without looking at the exact message.
Well, b1228 gets further. See attached. However for the offending track, nothing gets drawn. Then when I attempt any zoom, bang. Division by zero. Again, If I recreate these three items on their own in a playlist all is well! >:( (I’m also attempting a crash report).
Almost. See waveforms on track 1 & 3, but 2 is blank. Does not crash on zoom tho’
Now, if I hit play, track 2 appears BUT, Track 2 & 3 start simultaneously (I hear both) but visually separated. Then if I close Mix Editor and re-open, all is well. So, getting closer.
Ok, the actual origin of the problem is that the file has a reported duration of 0 (or just above 0). Perhaps mAirList failed to determine the actual duration? What kind of file is that? Does its duration show up properly in the playlist and/or Cue Editor?
Well, in this playlist it does report as no duration, YET, in another playlist, all drag and dropped from the database, it does show 0:08 as a duration. PFL reports a Fade out correctly. Humm. (I see why now, reason below)
Now, the entry in the database shows duration as 0:00, so yup, somehow that’s it. If I open PFL and OK to close it, the duration gets populated.
Looking closer, I see about 5 files (same import) that show NO duration in database. So, something went awry a few months ago!
Many thanks for your help and tracking down it.
Now, I’ll see why some durations got missed. The database entries all show a correct Fade Out
Well, I found about 6 Jingles in the database that had blank durations. I deleted the entry and re-imported and same issue. Traced it back to the MMD’s that showed a duration of 0. ( I create the MMD from my SPL2MMD utility that reads the APE tags).
APE tags checked out so I re-ran my utility and the new MMD’s showed all correct, so re-imported to database and all now checks out fine. Really don’t know what went wrong as these 6 tracks are part of a set of 18 and all were imported at the same time!
I appreciate the help and guidance and look forward to the VT bits (will that be beta’d?, I’m rather a good beta tester now!).
Ok, thinking further, I know why this didn’t happen in v4.0.0.1170:
Actually, the Mix Editor (as well as the Cue Editor) reads out the duration again when opening the file to generate the waveform. So even if the file has a reported duration of 0 in the playlist, the waveform generator will determine the correct duration, so it doesn’t really matter.
However, the process of opening the file was moved into a background thread in v4.0.1 - note the changelog entry:
[*] Waveforms: File is opened in the background for scanning, preventing short GUI freezes when a player is being loaded
So even though the waveform generator knows the exact duration, it hasn’t even started to work when the bitmap for the waveform (or the stub image showing the progress indicator) is allocated. So the incorrect width of 0 is assumed at that time.
I think we need a way to update the image width later when waveform generator has finally opened the file and knows the exact duration.
