Author Topic: 3.4 reports, queries and bugs  (Read 428133 times)

saga

  • Posts: 2298
Re: 3.4 reports, queries and bugs
« Reply #725 on: 27 Jul '09 - 18:15 »
Ah yes, I can imagine where that problem comes from (as I had to deal with the envelope loop length problem lately). Modules made with OpenMPT don't have this "off by one" problem anymore.

winner

  • Posts: 270
Re: 3.4 reports, queries and bugs
« Reply #726 on: 27 Jul '09 - 19:09 »
Hey, I don't think anyone has responded to my argument about random play. What does everyone else think? When starting playback of a song list with random play mode selected, wouldn't it seem natural that the first song played should be a random choice always?
Don't really care either way but for the sake of randomness, I guess it could be random. I use shuffle instead for more controlled randomness. :)
Well, "random" should be random, shouldn't it? If I have a large playlist which I like to play often in random order, it gets tiresome if every time I play it the same song starts the sequence, being the first song in the list by default (unless perhaps the "save playback position" setting is enabled). Immediately then I have to manually right click the play/pause button to get a different song. I understand that toggling the "random order" setting will establish a differently sorted list.

Is there a "shuffle" setting in the player gui, or just as a command line option? I also don't see an "autoplay" option in the gui, so that I can autoplay streaming audio when launching the player.

If anyone can respond to these questions I'd appreciate it. Thanks!

Pike84

  • Posts: 1398
Re: 3.4 reports, queries and bugs
« Reply #727 on: 27 Jul '09 - 22:18 »
There are both options for shuffling the playlist and for toggling random play; both can be accessed by right-clicking the small question mark on the GUI.

winner

  • Posts: 270
Re: 3.4 reports, queries and bugs
« Reply #728 on: 28 Jul '09 - 02:50 »
There are both options for shuffling the playlist and for toggling random play; both can be accessed by right-clicking the small question mark on the GUI.
Thanks Pike84; the skin I used did not have the question mark, but I see it on the default skin. Still, the problem of not starting with a random song remains. Also, apparently the shuffle option is not included on the "Options and stuff" dialog, which for completeness' sake should be present. For completeness' sake as well, I suggest that "autoplay" be included on the Playlist panel of "Options and stuff." Please pardon me if I am missing something!

Jace

  • Posts: 825
Re: 3.4 reports, queries and bugs
« Reply #729 on: 28 Jul '09 - 06:47 »
Also, apparently the shuffle option is not included on the "Options and stuff" dialog, which for completeness' sake should be present.

I believe this'd be what you're looking for. :)
(See attachment.)

Auren

  • Posts: 144
Re: 3.4 reports, queries and bugs
« Reply #730 on: 28 Jul '09 - 07:39 »
A cosmetic bug. Ian, could you please make a dropdown menu in "Output" settings bigger than initial control it is being invoked with? I ask for this because the name of the DS device is too long to fit in that small dropdown menu.

Here's a visualization of what I am talking about:


And here is how it currently looks like in XMPlay:

winner

  • Posts: 270
Re: 3.4 reports, queries and bugs
« Reply #731 on: 28 Jul '09 - 14:28 »
Also, apparently the shuffle option is not included on the "Options and stuff" dialog, which for completeness' sake should be present.

I believe this'd be what you're looking for. :)
(See attachment.)
Thanks Jace, but no, I'm aware of that setting. My point is that one should not have to manually toggle that setting to force XMPlay to use a new first choice when starting playback in random mode.

Given a static sequential list, if random play is selected, I'd expect XMPlay would select a truly random song in that list to play first, then go on to play other choices randomly without repeating any song before exhausting the list.

Ian @ un4seen

  • Administrator
  • Posts: 21682
Re: 3.4 reports, queries and bugs
« Reply #732 on: 28 Jul '09 - 17:23 »
Hey, I don't think anyone has responded to my argument about random play. What does everyone else think? When starting playback of a song list with random play mode selected, wouldn't it seem natural that the first song played should be a random choice always?

Are you referring to XMPlay playing the first track when loading a playlist or multiple files/directories? If so, that is because XMPlay won't wait for all the tracks to be added to the list before starting playback; it'll start playback immediately (assuming that is enabled via the "Open" or "Play listed tracks" options), which means it is unfortunately not possible for it to choose a random track, as it doesn't know about any other tracks still to come at that point.

A cosmetic bug. Ian, could you please make a dropdown menu in "Output" settings bigger than initial control it is being invoked with? I ask for this because the name of the DS device is too long to fit in that small dropdown menu.

Here's an update to try...

   www.un4seen.com/stuff/xmplay.exe


Auren

  • Posts: 144
Re: 3.4 reports, queries and bugs
« Reply #733 on: 28 Jul '09 - 18:34 »
Here's an update to try...

Thank you! Now the text is not truncated.

Tsorovan

  • Posts: 1247
Re: 3.4 reports, queries and bugs
« Reply #734 on: 28 Jul '09 - 20:47 »
Also, apparently the shuffle option is not included on the "Options and stuff" dialog, which for completeness' sake should be present.
That wouldn't make much sense, since "shuffle" is not a playback mode, it's a command to process (in fact reorder) the playlist.

guest

  • Guest
Re: 3.4 reports, queries and bugs
« Reply #735 on: 3 Aug '09 - 13:07 »
Focus isn't moved to box with matches in 'Find track(s)' window after clicking on scroll-bars of this box.

amit

  • Posts: 723
Re: 3.4 reports, queries and bugs
« Reply #736 on: 13 Aug '09 - 17:00 »
When attaching xmplay with skins like classic or bonjour to the bottom of the screen both the mini and regular modes stay adjacent to the screen edge.

When using a skin in auto-mini mode (like windows classic - automini) the mini mode  floats inside the screen area instead of staying along the screen edge.

Is it fixable?

saga

  • Posts: 2298
Re: 3.4 reports, queries and bugs
« Reply #737 on: 20 Aug '09 - 11:41 »
http://modarchive.org/module.php?56598 The very last three notes in this module play somehow at the wrong pitch - Maybe the Gxx effect is initialized wrong? I've compared the output with MPT and IT, and they both play it different (like if there was G00).

Auren

  • Posts: 144
Re: 3.4 reports, queries and bugs
« Reply #738 on: 21 Aug '09 - 13:44 »
XMPlay shows an incorrect bitrate of this stream:
Code: [Select]
mms://87.242.72.62/relaxfm?WMBitrate=166400&WMContentBitrate=166400
Here are the screenshots of WMP and XMPlay:



It looks like the server reports that the stream is WMA 9.2 32 kbit/s but the actual bitrate of the stream is 128 kbit/s

Dotpitch

  • Posts: 2878
Re: 3.4 reports, queries and bugs
« Reply #739 on: 21 Aug '09 - 16:08 »
It looks like the server reports that the stream is WMA 9.2 32 kbit/s but the actual bitrate of the stream is 128 kbit/s.
Actually, the transport stream has a bitrate of 166.4 kbit/s, and can contain a 128, 64 or 32 kbit/s audio stream. Both WMP and XMPlay use the first possibility for playback (128 kbit/s), but report the last one (32 kbit/s) as the one they use.

reinhart

  • Posts: 11
Re: 3.4 reports, queries and bugs
« Reply #740 on: 22 Aug '09 - 04:56 »
I have a thousand midi files. I can't open that files using "Open" button at the same time. But I can add that files to playlist using "Add Directory" button. Is it a bug?

Dotpitch

  • Posts: 2878
Re: 3.4 reports, queries and bugs
« Reply #741 on: 22 Aug '09 - 08:06 »
I have a thousand midi files. I can't open that files using "Open" button at the same time. But I can add that files to playlist using "Add Directory" button. Is it a bug?
The 'Open file'-dialog gives XMPlay the full path to every file, with a thousand files that probably exceeds the maximum length of what the dialog is capable of. Adding a directory gives XMPlay only the path to the directory, after which it to finds out itself what files are in there. This is not a bug, it's a limitation in Windows.

raina

  • Posts: 1163
Re: 3.4 reports, queries and bugs
« Reply #742 on: 30 Aug '09 - 14:25 »
There's a bug I noticed in 3.4.2.125 (and .124) where if XMPlay needs to start buffering a streamed file, it will resume playback once buffered regardless of the play/pause button state. In fact, if you press pause during buffering the button keeps blinking, as does the time display while still being updated.

Jimmy Neutron

  • Posts: 476
Re: 3.4 reports, queries and bugs
« Reply #743 on: 30 Aug '09 - 18:07 »
I have several URLs that will stream in Screamer as 320 or 256 mp3 with artist/title info but XMPlay (stuff 125) shows them as WMA with no artist/title.

I can bounce from one program to the other, and always get mp3 with Screamer and (after a long delay) get WMA with XMPlay.

I haven't had any such issues with lower definition streams.

Examples:
http://65.60.11.2:8044
http://94.75.235.38:8253
http://24.184.236.6:8000

What am I doing wrong?

Jimmy Neutron

Dotpitch

  • Posts: 2878
Re: 3.4 reports, queries and bugs
« Reply #744 on: 30 Aug '09 - 18:25 »
I have several URLs that will stream in Screamer as 320 or 256 mp3 with artist/title info but XMPlay (stuff 125) shows them as WMA with no artist/title.
http://65.60.11.2:8044
http://94.75.235.38:8253
http://24.184.236.6:8000
On all these adresses, I get an MP3 stream with high bitrate, so I suggest you try them again or get fresh links from the stations main site. Do they all host Windows Media streams as well, btw?

Jimmy Neutron

  • Posts: 476
Re: 3.4 reports, queries and bugs
« Reply #745 on: 30 Aug '09 - 22:13 »
I have exhausted my capabilities on this issue.  Visited the sites, tried the other streams listed, but can't get the high-bit-rate ones to work.

I've attached a screen capture with Screamer and XMPlay open to the same URL at the same time, and you can see that Screamer delivers it as mp3, and XMPlay does not.  What does the track info format of "MPEG Audio Layer=3" mean?

Pike84

  • Posts: 1398
Re: 3.4 reports, queries and bugs
« Reply #746 on: 30 Aug '09 - 22:25 »
What does the track info format of "MPEG Audio Layer=3" mean?
Basically, it just means mp3. So it seems like XMPlay only displays the wrong audio format in the main GUI view.

Jimmy Neutron

  • Posts: 476
Re: 3.4 reports, queries and bugs
« Reply #747 on: 30 Aug '09 - 22:39 »
Quote
Basically, it just means mp3. So it seems like XMPlay only displays the wrong audio format in the main GUI view.

Ummmmm...... OK, it shows the wrong audio format in the main GUI view, and it also shows WMA in the playlist view.  Frankly, it doesn't matter to me what the stream gets called, I just want to find a way to see the artist/title info.

I'm going to re-download the official XMPlay distribution file and install it into a clean, empty directory and run it with NO configuration changes or add-ons.

Wish me luck....

Jimmy Neutron

  • Posts: 476
Re: 3.4 reports, queries and bugs
« Reply #748 on: 30 Aug '09 - 22:55 »
Hmmm... replying to myself?  Too much time on my hands!

OK, I downloaded the official XMPlay archive and expanded it.  I dropped one of the offending .pls files onto the main window, and it immediately started playing in mp3 format with artist/title, just fine.

I shut XMPlay down, I downloaded the "stuff" 125 version, and copied it into the clean XMPlay directory.  Started it up, and again dropped the same offending .pls files onto the main window.  It displayed "buffering..." for a very long time (at least 15-20 seconds) and then decided the stream was WMA, and did not display the artist/title.

This is straight out of the box, didn't touch any config entries, no new .dlls, nothing.

Is this enough to start tracking down the cause of my issue?

Dotpitch

  • Posts: 2878
Re: 3.4 reports, queries and bugs
« Reply #749 on: 31 Aug '09 - 07:18 »
So it seems like XMPlay only displays the wrong audio format in the main GUI view.
Yes, I now see that too.
Frankly, it doesn't matter to me what the stream gets called, I just want to find a way to see the artist/title info.
A quick look at the network traffic showed that XMPlay opens the ShoutCast stream and for some reason stops it again, and then lets the Windows Media libraries (User-Agent:WMFSDK/11.0) handle the streaming. Windows Media does not support metadata in the stream, so the server does not send it. The long time to detect the stream is also a flaw of Windows Media. The stream is still MP3 as shown in the General tab, but since the Windows Media libraries are decoding it, XMPlay assumes it's WMA.
It all comes down to XMPlay thinking it cannot play the ShoutCast stream by itself.