I've noticed a very strange behaviour in WMP11 seeking.
All my audio file are in WavPack format with APEv2 tagging except for 13 files (old mp3's).
As anyone as suffered since the upgrade of WMP, i'm no more able to seek my WV files.
EXCEPT, in a playlist i've created, where there's less than 50 files and where WavPack files are mixed with mp3's...
As the developper of WMPTSE, i now know that my plug-in is no more the problem.
But as a USER, i very like to know what the f*** is doing WMP.
Could some of you repeat the experiment...
Place some "unseekable under WMP11" files in a small playlist with some MP3 and post the result here...
May be i could fine a workaround...
Yeah, I just recently downloaded your extension and I love it. Although I have noticed that while I play my .ogg files, I cannot seek throughout the song. When I try, it simply starts the track from the beginning. I also tried mixing it with .mp3's and that did not work as well.
Oddly enough I did happen to notice it working after looking in the properties of the extension (and possibly refreshing the extensions, I cannot remember accurately), but after trying more .ogg files it continued to not work.
Hope you figure out a workaround, it's a great extension and I like the WMP11. I'd hate to go back to using mediamonkey for the sake of my .ogg files and iriver clix.
Me again, from playing around with it again, I noticed that it does not work when you play a song from the library. Even while looking at the properties of the file withing WMP11, it says 0kbps as a bitrate, gives no song length, etc. Whether if I dragged the same song file into the Now Playing list from Windows Explorer, the song length shows, the seeker works as it should, and all the information is displayed in its properties within WMP. I do not know why this happens and I hope you can figure it out.
I need to investigate more.
It seems like a conjunction of a bug in the directshow codec and in WMP.
The length, duration and bitrate are delivered by the DirectShow codec. It seems like sometime, it simply does not provide it to WMP11.
Some other time, it does. But then, depending on wether you're in a long playlist (ex. your library) or in a tiny one, seeking doesn't or does work.
I've tried with many WavPack files. Some do work every time. Some do never work anytime. And some do work in "Now Playing".
I guess we have a very difficult bug here.
The problem is, i couldn't entirelly attribute it to the directshow codec. It seems that WMP11 is also messing things up.
A workaround inside WMPTSE will be difficult.
The bug may be triggered by the tiny lag when WMPTSE read the tags from the file just before the file is played (if the file is in the Library).
I've to test more hypothesis.
The more you give me detailed scenario, the more we can locate the buggy behaviour...
Working on it...
So far the behavior of wmp that I explained above hasn't changed (the seeker won't work unless I directly move the .ogg file from windows explorer into the wmp 'now playing' list). Unfortunately .ogg is the only file type that I have that causes problems (the only other file types I use are .mp3 or .wma) but it seems as if the types of symptoms you have for your "WavPack" files are very similar to those of my ".ogg". When I get the chance, I will play around with my setup and give you more details on wmp/wmptse's behavior.
MP3 and WMA are native format of the Windows Platform. It's the least they can do to support it totally.
Our problem rise when playing non-Microsoft(+MP3) format.
But research done, it seems the problem really is only in the directshow codec : http://www.hydrogenaudio.org/forums/index.php?showtopic=51746&hl=.
The question is raised for illiminable (and it seems that unstable version resolve it), but also for other directshow codec (CoreCodec anyone ?)
I guess you'll have to try the illiminable unstable directshow codec...
Alright, I have tried some different combos and still messed up.
Coreflac with WMPTSE 1.4 still no seek with flac
and i have tried to unstable from illuminable and no seek from library wiht wmptse 1.4, however if loading from win explorer (vista ultimate x86) it will work but then it crashes.
I am having a very similar, if not the same, problem. I am running WMP11 on vista with haali, ffdshow, and both tag extenders that i can find. If you play a .mp4 file from windows explorer it will play just fine, able to seek, and all. But if you add the file to the library and launch it from the library, it will play but not seek. On the same note, if you launch the file from explorer, stop the file, and open the same file from the library it plays just fine. The only thing I can assume is that when WMP starts the video it only references its database for the file properties rather than getting all the info from the original file. I believe that if we can force media player to read the file properties and not just the tags it will play files fully from the library.
Yea I was seeing the same behavior (including no song lengths showing up at all) until I installed WMPTagEXT 1.4 and now it works perfectly. Now if I can just figure out how to get album covers for my FLAC albums in WMP *sigh*
Well it seems I spoke too soon. I did have everything working and now the problem has returned. It seems like WMP no longer recognizes any length values which seems to be somehow related to slider issue. Back to the drawing board...
I'm still trying to get FLAC to work in WMP11 under XP MCE 2005, and I see how much work went into this. I'll post my testing results in the WMPTSE thread at hydrogenaudio.org.
After doing some debugging, I have noticed that IWMPMedia::get_duration()* call gives different results for the same file under different circumstances.
file is not in library.
Play file via explorer or File->Open.
get_duration() will return the correct value (e.g. 456) from the DirectShow filter's GetDuration().
file is in library.
Play file via library.
get_duration() will return 0 even if GetDuration() is returning the correct value.
file is in library.
Play via explorer or File->Open.
get_duration() will return an oddly incorrect value (e.g. 0.456). Filter's GetDuration() still returns the same correct value in all three cases.
It appears that WMP's display UI is using get_duration() or get_duration() is using the same method of getting the file's duration and that has a bug. I don't know... Any one have a solution?
Note *: Retrieved the current IWMPMedia from the IWMPCore's current playing file after an OpenStateChange event of MediaOpen is sent as the documentation says you need to do.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.