Author Topic: 3.6 reports, queries and bugs  (Read 186811 times)

Dotpitch

  • Posts: 2845
Re: 3.6 reports, queries and bugs
« Reply #75 on: 10 Feb '11 - 18:57 »
Read here.

tails_

  • Posts: 74
Re: 3.6 reports, queries and bugs
« Reply #76 on: 10 Feb '11 - 19:04 »
Oh and about rsn format (RARed SPC tunes). In older version (3.4 iirc) they were opened with rar unpacker and all tunes was visible in playlist but now i get only 1st tune from archive with rsn extention (so it looks like unpacking handled by input plugin).
Btw can be "priority filetypes" added like for input plugins?

Pike84

  • Posts: 1398
Re: 3.6 reports, queries and bugs
« Reply #77 on: 12 Feb '11 - 15:36 »
To achieve gapless playback, the next track needs to be ready to go before the current track finishes playing. So once the current track has finished decoding, XMPlay will close it and open the next one. That allows the next track to take up to the length of the output buffer to become ready without introducing a gap. That transition won't normally be obvious because the title/etc display won't be updated until the next track is actually heard (you can see it in the playlist though), but if you press stop during it, then the display will be updated immediately to reflect the new current track.
Thanks for the explanation. I'm not sure I understand all of this functionality, but still...

Can it be "fixed" though?
:P

I'd like the track change to always occur exactly when the timer/title change says so - I don't even care if the next track would have to be completely preloaded into memory or something like that, I just want it to be spot on, regardless of the buffer setting. The problem I described earlier is still there.

Chinese Sausage

  • Posts: 424
Re: 3.6 reports, queries and bugs
« Reply #78 on: 12 Feb '11 - 21:15 »
I suspect it may actually be with "Auto-resize" disabled. XMPlay will try to retain the info window size then, but that may not be possible while keeping a whole number of playlist/library entries displayed. Here's an update that should at least not always favour shrinking the window over expanding it in that case...

There is a similar problem with the Extended Playlist/Library window width, as it tends to grow in size when changing skins (with "Auto-resize" disabled).

Did you happen to have the window set skinny? If so, it could be that it was too skinny for some skins; each skin has a minimum window size determined by the size of its bitmaps. If the problem is happening even with the window set wide, please give 2 skins that demonstrate the problem when switching between them.

The window is not set in what I consider skinny, it has a considerable good size for the info being displayed. I only noticed this problem when switching to the Aiwa skin. There is a change in size with some of the other skins (WMP 10, A-Round), vertically, although not as much as it used to be.

Ian @ un4seen

  • Administrator
  • Posts: 19368
Re: 3.6 reports, queries and bugs
« Reply #79 on: 15 Feb '11 - 17:46 »
I'd like the track change to always occur exactly when the timer/title change says so - I don't even care if the next track would have to be completely preloaded into memory or something like that, I just want it to be spot on, regardless of the buffer setting. The problem I described earlier is still there.

OK, here's an update that adds a "NoPreload" XMPLAY.INI option to disable the preloading of the next track (unless crossfading is enabled)...

   www.un4seen.com/stuff/xmplay.exe

Note that it will also prevent gapless playback.

The window is not set in what I consider skinny, it has a considerable good size for the info being displayed. I only noticed this problem when switching to the Aiwa skin. There is a change in size with some of the other skins (WMP 10, A-Round), vertically, although not as much as it used to be.

The minimum width of the Aiwa skin info window is 580 pixels, which is pretty wide. Did you have it skinnier than that before switching to the Aiwa skin?

You can tell whether the info window is as small as it can be by trying to make it smaller :)

Pike84

  • Posts: 1398
Re: 3.6 reports, queries and bugs
« Reply #80 on: 15 Feb '11 - 18:58 »
OK, here's an update that adds a "NoPreload" XMPLAY.INI option to disable the preloading of the next track (unless crossfading is enabled)...

   www.un4seen.com/stuff/xmplay.exe

Note that it will also prevent gapless playback.
Maybe you guessed it already, but this isn't exactly what I was looking for...

As I said, I don't really understand the problem. Why can't you just make the player preload part of the next track, then anticipate/compensate for the buffer, so that the title change occurs at the same time as the track change?

It's not a big deal, and was partly because I had too big a buffer setting - I guess I'll just set it to minimum for now.

Chinese Sausage

  • Posts: 424
Re: 3.6 reports, queries and bugs
« Reply #81 on: 15 Feb '11 - 19:14 »
Is the change on the same 3.6.0.8 version? :O

Ian @ un4seen

  • Administrator
  • Posts: 19368
Re: 3.6 reports, queries and bugs
« Reply #82 on: 18 Feb '11 - 13:40 »
As I said, I don't really understand the problem. Why can't you just make the player preload part of the next track, then anticipate/compensate for the buffer, so that the title change occurs at the same time as the track change?

That is what should already happen, ie. the title display shouldn't change until the next track starts to play. To illustrate the problem you're seeing, perhaps you could make a little video (with sound) of it occurring?

Fraggie

  • Posts: 705
Re: 3.6 reports, queries and bugs
« Reply #83 on: 23 Feb '11 - 17:31 »
If title tag is not present, but artist is defined, then the library will get full formatted string as the title instead just of the file name.

So with default formatting string, the library shows in this case something like "Artist - filename.ext" as the title.

Pike84

  • Posts: 1398
Re: 3.6 reports, queries and bugs
« Reply #84 on: 24 Feb '11 - 09:06 »
That is what should already happen, ie. the title display shouldn't change until the next track starts to play. To illustrate the problem you're seeing, perhaps you could make a little video (with sound) of it occurring?
Ok, I'll try try to make something like that when I have the time.

As I said, when I stopped a track close to the end (definitely before the track change), I lost the following queue item as a result. My buffer setting was at 0.7s IIRC.
« Last Edit: 24 Feb '11 - 12:23 by Pike84 »

saga

  • Posts: 2049
Re: 3.6 reports, queries and bugs
« Reply #85 on: 29 Mar '11 - 21:34 »
I'm not sure whether the following problem is related to VBR files, so I've uploaded an example (saga-reconstruct.zip)...
I have a rather big mp3 file and after having played like half an hour of it, seeking forwards/backwards (using left/right key) always seeks to a point that is a few seconds before the current point, i.e. even with seeking forwards I get to a point that has already been played! Similary, the cue points in the the corresponding .cue file seem to get off-sync - XMPlay displays the last few cue points at a time that is off a few seconds from the intended cue time (confirmed with an audio editor).

Pike84

  • Posts: 1398
Re: 3.6 reports, queries and bugs
« Reply #86 on: 30 Mar '11 - 00:43 »
This sounds like it could be related to the problem I described earlier. Sorry, that I haven't had the motivation to try and dig into it further :-[ - it's been such a minor nag.

Ian @ un4seen

  • Administrator
  • Posts: 19368
Re: 3.6 reports, queries and bugs
« Reply #87 on: 30 Mar '11 - 16:01 »
I'm not sure whether the following problem is related to VBR files, so I've uploaded an example (saga-reconstruct.zip)...

Yep, VBR MP3 files unfortunately have poor seeking accuracy, and the larger the file, the less accurate it is. That's because an "Xing" seek table contains only 100 points. XMPlay will interpolate for positions between the seek points, but the table's file positions aren't very accurate either, being only accurate to within 1/256th of the entire file size. That means with a 74 minute and 100MB file (like yours), there is a seek point every 45 seconds, which has a file position that is accurate to within 390KB. So not very accurate :)

saga

  • Posts: 2049
Re: 3.6 reports, queries and bugs
« Reply #88 on: 30 Mar '11 - 18:02 »
OK, I guess this also applies to the cue point seeking problem then? Or is seeking to cue points accurate?

Ian @ un4seen

  • Administrator
  • Posts: 19368
Re: 3.6 reports, queries and bugs
« Reply #89 on: 31 Mar '11 - 14:27 »
Yep, the seeking accuracy will affect the CUE points too (seeking to a CUE point is basically the same thing as moving the position slider there yourself). XMPlay will use the VBR seek table to translate the time position to a file position but, as mentioned, that isn't very accurate.

piovrauz

  • Posts: 962
Re: 3.6 reports, queries and bugs
« Reply #90 on: 31 Mar '11 - 14:39 »
mmm, does this affect just mp3 vbr or also other vbr lossy codecs? like musepack, or vorbis?

Ian @ un4seen

  • Administrator
  • Posts: 19368
Re: 3.6 reports, queries and bugs
« Reply #91 on: 31 Mar '11 - 16:39 »
Other VBR codecs may have inaccurate seeking too, but that isn't necessarily the case. For example, OGG does have accurate seeking. I'm not sure about MPC, I seem to recall the decoder scans the file for seek points. Actually, as XMPlay is already scanning the MP3 file for the correct length, it may as well build a seek table at the same time. Here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

Note the MP3 file scanning occurs after playback begins. That avoids playback being delayed, but it does mean that when resuming a saved position the normal (possibly less accurate) seeking will have to be used to get there.

moriez

  • Posts: 109
Re: 3.6 reports, queries and bugs
« Reply #92 on: 11 Apr '11 - 19:02 »
SingleClickTray does not work here when another window is maximized and On top is unticked. I can only get it to work when I first press right mouse. Does anyone else experience this? I'm on XP.

Jimmy Neutron

  • Posts: 472
Re: 3.6 reports, queries and bugs
« Reply #93 on: 11 Apr '11 - 20:29 »
SingleClickTray works as expected here.  I've maximized a Firefox window, and brought XMPlay up (and visible) and down (to the tray) with a single click.

Win 7 x64 desktop.

I'm not sure about XP, or if there's something else getting in the way for you.  Does your issue happen with ANY  maximized program, or just particular ones?

Edit: What version exactly of XMPlay?  Skin?  Vis?

moriez

  • Posts: 109
Re: 3.6 reports, queries and bugs
« Reply #94 on: 12 Apr '11 - 00:10 »
With what I've tested any maximized window: apps or windows explorer does not matter. On the desktop it works flawlessly. It is not the Lithe skin as it's the same with the default. Neither is it something in the .ini file. I moved it away to test that. Version is 3.6.0.12 and no vis. It works fine when I tick ''On top'' but then it's on top what I don't want :)  Did you test without ''On top''?

Jimmy Neutron

  • Posts: 472
Re: 3.6 reports, queries and bugs
« Reply #95 on: 12 Apr '11 - 01:30 »
Did you test without ''On top''?

I don't do "on top" ... it drives me nuts.

In the xmplay.ini I have SingleClickTray=1 and in the on-top section of the options screen, I have only "Always in Tray" checked.

Not sure what else you could try, except perhaps a different computer?

Chinese Sausage

  • Posts: 424
Re: 3.6 reports, queries and bugs
« Reply #96 on: 12 Apr '11 - 01:47 »
Indeed, when on top is not checked, you have to double-click the tray icon to restore it, instead of a single click.

Pike84

  • Posts: 1398
Re: 3.6 reports, queries and bugs
« Reply #97 on: 12 Apr '11 - 23:55 »
"SingleClickTray=1" works fine here on Win 7.

moriez

  • Posts: 109
Re: 3.6 reports, queries and bugs
« Reply #98 on: 13 Apr '11 - 16:15 »
Indeed, when on top is not checked, you have to double-click the tray icon to restore it, instead of a single click.

You're on XP as well?

Ian @ un4seen

  • Administrator
  • Posts: 19368
Re: 3.6 reports, queries and bugs
« Reply #99 on: 13 Apr '11 - 16:29 »
Do you have the "Always in tray" option enabled? If so, double-clicking (or single-clicking if "SingleClickTray" is enabled) can both restore and minimize XMPlay. So perhaps what's happening is that when you first click on the tray icon, XMPlay isn't yet minimized (it's just covered by other windows), so it becomes minimized at that point and you then have to click again to restore it.