63 replies to this topic

[bLight]

It's finally ready! The most visually polished version of Zoom Player EVER!
I hope everyone enjoys this release, the team worked long and hard to make sure v8.5 is a great success.

The FREE version will be released next week, PRO and MAX users can download right away and start playing:
Download Zoom Player v8.5 MAX.
Download Zoom Player v8.5 PRO.
Download Zoom Player v8.5 FREE.

For the full change log from v8.1.6, click here.

What changed since v8.5 RC1:

  * The LAV Video decoder can now be selected as a DVD video decoder.
    LAV's DVD support is still experimental.

  * The PowerDVD 12 video decoder is now supported for DVD decoding.

  * The OPUS Audio format is now fully supported.
    Existing users may want to click on the 'Default' button next to the audio
    file extensions under:
    Adv. Options / File Format Association / File Extensions

  * Zoom Player now supports the Open-Source DVD Navigation filter:
    http://sourceforge.net/projects/dslibdvdnav/

  * New fullscreen navigation skin-scripting parameter to set the playlist's
    active playing track color, when it is the selected entry.

  * An LAV Video decoder option has been added to the Theora Video
    Smart Play profile.

  * A new Theora Video sub-type has been added to the Smart Play profile.

  * A new warning dialog now pops-up when trying to enable certain conflicting
    settings in the options dialog.

  * When selecting items in the fullscreen navigation interface, for additional
    clarity, an icon is now used to mark the selected entry.

  + The uTorrent and eMule download percentage in the fullscreen navigation
    interfaces has been changed to a more suitable color and is now aligned
    to the left of the file name.

  + The mouse wheel's Increase/Decrease play rate function now works in
    10% increments.

  + The function list dialog's search function has been enhanced for clarity.

  + Smart Play now strips the '.!ut' file extension when evaluating which
    source filter to use. This change should improve playback stability of
    incomplete media files downloaded with uTorrent.

  + More Smart Play profiles now provide an 'LAV' option to use as the
    decoder/splitter.

  - Fixed several memory leaks, especially when loading skins or
    expanding/contracting skin elements.

  - Several bug-fixes to the FFDShow and VobSub's Subtitle rendering filter's
    subtitle track cycling.

  - Multiple bugs fixed in the subtitle track selection dialog, including:
    Active subtitle track was not always detected.
    A 'disabled' subtitle track entry was not always present.

  - When using MadVR as the video renderer, Zoom Player now exits
    fullscreen exclusive at the end of each track, increasing MadVR
    stability (no more fullscreen freezes between tracks on some
    systems).

  - Changing the fullscreen navigation's 'navigation line count' value
    no longer distorts the 'Path' icon size in the following fullscreen
    navigation interfaces:
    1. Media Library.
    2. File Browser.
    3. Station Browser.
    4. Download Manager.

  - When setting the fullscreen navigation's 'navigation line count'
    value to a high figure, the Equalizer and Color Control navigation
    interface's display became too small to read.

  - When using 'automatic subtitle stream selection' with multiple
    'text match' values, the last matching text was used instead
    of the first matching.

  - The current media's Scene-Cut list would get wiped clear when switching
    skins or expanding/contracting skin elements.

[bkm]

Edit : Never mind, got it :-)

[ehathgepiurhe]

Thanks to bLight and the gang for the continued development of Zoom Thanks to the community as well (for bug reports, feature requests etc), and to the closed testing group also (for their help in testing Zoom).

ehat

[boogafreak]

Yey for a great final version!

[wdekler]

Nice! Thanks for the update!

Maybe it's a good idea to use the latest 0.52 LAV filters now that everyone is running the install center? Or are they still in testing?

[ehathgepiurhe]

Hi wdekler,

LAV 0.52 is still being tested, as is madVR 0.84.3 - bLight is also waiting to see if nev releases a 0.52.1 before he pushes 0.52 out to Install Center. He does hope though that both updates may be up on Install Center in the next few days.

(LAV 0.52 is required to use the LAV Video profile for DVD decoding)

ehat

[TheLandYacht]

Awesome. Thanks guys for the continued support!

[tvholic]

How about the Premium version?

[Funkdvoid]

Thank you for making something great even better!

[boogafreak]

How about the Premium version?

We will publish the Premium link as soon as we have it.

[boogafreak]

Ok - here's the new Premium version :
http://dl.zoomplayer.com/zp850prm.exe

Booga

[Shadrach]

Awesome, finally it's out. I agree it is really polished. I love the skinned menus, they add so much to the overall look, and the "new" skin is so cool!

I guess the idx/sub thing I reported is assumed to be a bug in FFDShow, or are they still working on it?

[tvholic]

Thank you.

The "Very Long Seek" functions haven't been added to the default.key file:

AddKey(Ctrl+Shift,190,fnSeekLongForward)
AddKey(Ctrl+Shift,188,fnSeekLongBackward)

[TheShadowRunner]

Thanks for this great new build.
A couple bugs and oddities I noticed:

1. If I have a folder with 4 files in it, 2 .avi videos and 2 .jpg images, and start playing a video, when I press the "next track" button ZP will eventually open the images.
Expected behavior: ZP should only play the 2 .avi files and disregard the images.
I know it's not directly related but "Opening a drive or directory includes opening image files (JPG / PNG / BMP / etc...)" feature is unchecked.
I'm pretty sure on older builds ZP used to disregard all image files..
It makes no sense to me ZP currently opens the images, as images don't even show up in the "Open File" dialog with the default "Media Files" file type selected.

2. Even though I have the very latest Vobsub installed (v1.6.4.6052 from 2012-10-01), I was prompted at first boot that my version was outdated.
In fact, it is xy-VSFilter_3.0.0.65 that's outdated. The newer MPC-HC VSFilter mentionned above fixes a major bug in .PGS subs.

3. The main annoyance: going from one video to the next with madVR has become slower versus ZP version 8.16.
I suspect this change is responsible:

- When using MadVR as the video renderer, Zoom Player now exits
fullscreen exclusive at the end of each track, increasing MadVR
stability (no more fullscreen freezes between tracks on some
systems).

It seems there is some sort of new delay in order to achieve this.
In fact madVR was perfectly stable already when "Display OSD through MadVR's OSD API (preserves fullscreen exclusive mode)" was disabled.
bLight, could you enforce this workaround only when "Display OSD through MadVR's OSD API" is enabled?
For those of us who don't use it, we'll get our speed back.

4. Finally when pressing the "?" button at Playback > Video > Video Renderer", the information window that details the different renderers specs is so big it cannot be closed! (OK button at the very bottom is hidden) ;;

[ehathgepiurhe]

LAV 0.52 is still being tested, as is madVR 0.84.3 - bLight is also waiting to see if nev releases a 0.52.1 before he pushes 0.52 out to Install Center. He does hope though that both updates may be up on Install Center in the next few days.

Install Center updated.

I guess the idx/sub thing I reported is assumed to be a bug in FFDShow, or are they still working on it?

I reported it in the ffdshow thread on Doom9 - I wouldn't expect a fix though to be honest, ffdshow developing is pretty much dead I think.

The "Very Long Seek" functions haven't been added to the default.key file:

Just curious - why do they need to be added to default.key?

3. The main annoyance: going from one video to the next with madVR has become slower versus ZP version 8.16.
I suspect this change is responsible:

- When using MadVR as the video renderer, Zoom Player now exits
fullscreen exclusive at the end of each track, increasing MadVR
stability (no more fullscreen freezes between tracks on some
systems).

It seems there is some sort of new delay in order to achieve this.
In fact madVR was perfectly stable already when "Display OSD through MadVR's OSD API (preserves fullscreen exclusive mode)" was disabled.
bLight, could you enforce this workaround only when "Display OSD through MadVR's OSD API" is enabled?
For those of us who don't use it, we'll get our speed back.

I will check the others later when I have some time (with #1, I think there was a change to the default options for Zoom in 8.5 regarding images opening, and I think there is some confusion as well about what the option you quoted does - I don't think it does what you expect it to do, so I am not convinced there is actually a problem here).

I wanted to briefly address #3 right now however, as I would have to oppose any changes at all to this change in Zoom. It is the single most important thing about the new version for me, and took a lot of effort on my part to ensure it wasn't forgotten about in the 8.5 final code. There are a number of things to note about that particular change:

1. The change had nothing to do with the OSD or OSD API.

2. madVR wasn't stable - there was a repeatable hard Zoom crash with the way Zoom was exiting from FSE mode when moving from video file to video file (#304). This affected my system quite badly.

3. There was also a very noticeable (and annoying) visual glitch when moving from video file to video file in FSE mode (#314). This affected a number of us, myself included.

4. I believe that madshi has added the exact same behavior to madVR, so you would need to get him to revert his change as well. He made the change in madVR to prevent crashes and increase stability - the same reason it was added in Zoom in fact - and I would think that it would need to be a pretty strong argument for him to revert them. He also reverted some code to fix that same visual glitch in Zoom as a separate thing. These changes were made in the versions after 0.82.5 if I recall correctly, you may find the display delay speed with 0.82.5 acceptable.

5. The slowdown in speed between videos has been linked on Doom9 to the changes madshi made in madVR, and if I remember correctly from the madVR thread, madshi addressed them by improving the speed as much as he could without compromising the code changes he had made to increase stability and decrease crashes with the renderer.

6. There was another change made to 8.5 that may affect your perception of things - a black screen is now shown when moving between media files, to remove the flashing of the media background image that was another bug. This should not affect the actual speed of moving between files, but as your eyes no longer notices anything but a black screen, it is possible that your perception will have altered.

At a single code change in Zoom, two bugs were squashed - the crashes vanished, as did the visual glitch, and I believe consequent changes in madVR causes the issue you are referring to. The whole thing - from the Zoom side - was discussed pretty well in the thread for the fsefix build I posted (the fsefix code is the bit that you quoted from the changelog), which was well before the final version was released:
http://forum.inmatri...opic=13683&st=0 (the speed of moving between files was also noted, for example post #13 by nx6)

Putting aside my belief that madVR and not Zoom is responsible for the increased delay, technically, you could argue that if madshi made the same changes in madVR (to fix the crashes and visual glitches), then the changes in Zoom could be reverted. I'd argue the opposite - the changes in Zoom protect against madshi reverting his changes. If he reverts the way madVR exits from FSE mode, then without that change in Zoom, the crashes and visual glitches return. With the change in Zoom, madshi can revert all he likes, and it won't make a difference. It's insurance basically.

ehat

[ehathgepiurhe]

Ok, with #3 out of the way, let's look at the others.

1. If I have a folder with 4 files in it, 2 .avi videos and 2 .jpg images, and start playing a video, when I press the "next track" button ZP will eventually open the images.
Expected behavior: ZP should only play the 2 .avi files and disregard the images.

No, the toolbar buttons are mapped to the 'next/previous media file in folder' function, and images are media files, so toolbar buttons working as expected. Page Up/Page Down will do what you expect (as long as you don't use it while the image is open), as these are mapped to the 'only same file extension' function.

I know it's not directly related but "Opening a drive or directory includes opening image files (JPG / PNG / BMP / etc...)" feature is unchecked.

That only affects when you use the 'open drive' or 'open directory' options in Zoom. Nothing more, nothing less.

I'm pretty sure on older builds ZP used to disregard all image files..

I'd suggest checking again, as I don't believe anything has changed with the toolbar buttons...

It makes no sense to me ZP currently opens the images, as images don't even show up in the "Open File" dialog with the default "Media Files" file type selected.

I just don't see a problem here I'm sorry. It all looks to be working as expected to my eyes.

2. Even though I have the very latest Vobsub installed (v1.6.4.6052 from 2012-10-01), I was prompted at first boot that my version was outdated.
In fact, it is xy-VSFilter_3.0.0.65 that's outdated. The newer MPC-HC VSFilter mentionned above fixes a major bug in .PGS subs.

I will ask bLight, but I wouldn't be surprised if nothing can be done. Unfortunately, multiple projects have decided to name the .dll the same thing. As the filenames are the same, how is Zoom expected to know which project you have added the .dll from? I don't think there is a way - all it can do is to look up the md5 of the correct (installed by Install Center) dll file, compare it to yours, and then assume if the two are different, then your copy needs to be updated. Which is exactly what it is doing. The only way around it AFAIK would be to remove vobsub via Install Center, and then just install your version outside of Install Center (though Install Center will then always tick vobsub when you open it, but there is nothing you can do about this).

4. Finally when pressing the "?" button at Playback > Video > Video Renderer", the information window that details the different renderers specs is so big it cannot be closed! (OK button at the very bottom is hidden) ;;

I will re-open the bug, but I don't think the dev's can fix this fully without ditching the new skinning totally. Firstly, the font size needs to be fixed for each individual skin (It was fixed for Onyx, that is why the bug was closed), and secondly, if you have a resolution below a certain size, this still won't fix the issue either (for example, Onyx HD on my 1200 vertical resolution still has this problem). The bug has been opened and closed so many times it is like a revolving door.

ehat

Edit: The bug for #4 (#339) was only re-opened a few days ago by myself, so nothing to be done for the moment.

[TheShadowRunner]

ehat,
You may have had a bug, i don't doubt it for a second, but

1. You did have "Display OSD through MadVR's OSD API" enabled while doing all the testing, right..?

2. It was perfectly stable here..

3. See 1.

4. & 5. I was the one on doom9 that asked madshi to restore the previous code (to speed things up when going from one video to another with madVR) so yes i do know about this change.
But it doesn't apply here I'm afraid: I use the exact same madVR build v0.84.3 with the exact same settings, on both ZP 8.16 and 8.50. The difference is 100% due to ZP.

6. There was another change made to 8.5 that may affect your perception of things - a black screen is now shown when moving between media files, to remove the flashing of the media background image that was another bug. This should not affect the actual speed of moving between files, but as your eyes no longer notices anything but a black screen, it is possible that your perception will have altered.

Oh wow now this is very interesting and could very well be it.
Indeed, going from one video to the next on ZP 8.16 doesn't force a black screen between them.
I never experienced this "media background flashing bug" either...
It would be ideal if bLight could make this workaround optional so those who didn't have the bug in the first place don't have it forced on them.

[ehathgepiurhe]

1. You did have "Display OSD through MadVR's OSD API" enabled while doing all the testing, right..?

As the only way to keep madVR in FSE mode if you enable the Zoom OSD, yes, I did have that setting enabled.

2. It was perfectly stable here..

Certainly, I never believed for a moment that there wasn't a specific set of circumstances required to produce it (hardware, filters, Zoom+madVR options etc), and as such, I did realise that not everyone would be affected by this. In fact, I suspected that most people weren't being affected, as the forum wasn't being flooded with crash reports - having said that, I don't know if the Inmatrix guys received any via their emails or not however. Though obviously only a small portion of people use madVR anyway, so there wouldn't be a huge amount of reports even if 100% of madVR users reported the same issue (whether via forum or email).

3. See 1.

4. & 5. I was the one on doom9 that asked madshi to restore the previous code (to speed things up when going from one video to another with madVR) so yes i do know about this change.
But it doesn't apply here I'm afraid: I use the exact same madVR build v0.84.3 with the exact same settings, on both ZP 8.16 and 8.50. The difference is 100% due to ZP.

Assuming the two versions of Zoom are on the same system and you only have a single madVR installation, it would indeed seem logical that if the two versions of Zoom behave differently with that single madVR install, then something in Zoom is causing the difference.

Oh wow now this is very interesting and could very well be it.
Indeed, going from one video to the next on ZP 8.16 doesn't force a black screen between them.
I never experienced this "media background flashing bug" either...
It would be ideal if bLight could make this workaround optional so those who didn't have the bug in the first place don't have it forced on them.

Yes - I see the introduction of the black screen (which was a fix for bug #253) is not listed in the release announcement above (as a 'black screen now shown between media files' sort of entry). I guess it was considered too trivial for a release announcement to bother with listing.

I *think* the changelog (http://inmatrix.com/..._whatsnew.shtml) sort of mentions it. Assuming I am looking at the right entry (if I'm not, then it isn't listed in the changelog either), it implies that it may only apply to audio files, which I believe is incorrect - I'm pretty sure bLight made it apply to all media files. Regardless of whether the fix is mentioned anywhere, I knew for sure that this didn't affect everyone. I logged the bug in February - it took 7 months of backwards and forwards (mostly because bLight couldn't produce it on his system) to get that fix. I didn't actually ask at the time, but I wouldn't be surprised if bLight never actually managed to produce the problem at all, and in the end just made an educated guess at what might prevent it for me (i.e. making Zoom show a black image between files). I wouldn't have an issue with making this fix optional if it improved things for other people (just as long as I can leave it enabled, that media background image flashing is incredibly annoying).

The only objection I have to making the madVR crash fix optional is that your solution is not really optional - well, not by my definition anyway. If bLight disables that code for the madVR OSD API option, then you have no real choices (yes, I can see how that applies now, to people who don't want the fix). A better way of explaining it is that if you wanted to disable that OSD API option, you would not have the benefit of the code fix even if you wanted it, because it will have been disabled.

What I would support though is to introduce a new option into the Zoom options dialog. It doesn't matter what it would be named, but presumably something like 'Force madVR to stay in fullscreen exclusive mode between each track'. I'd prefer this to be disabled by default (but that's not a huge thing either way), and I think it should warn - via a pop-up when you enabled it, as some of the other Zoom options do currently - that by enabling the option, you increase your risk of Zoom instability. However, once enabled, the part of the code that introduces the fsefix is bypassed. That to me would meet the definition of 'optional' - basically if you disable the OSD API option, then the fix bypass is not forced on you, as you can simply leave the new option enabled. If you wanted to disable the OSD API option and disable the fsefix code, then you could - by disabling one option and enabling the other. And for me - who wants both the OSD option enabled and the fsefix code in place - I can simply leave the defaults alone. Everyone has their own choice this way.

Whether bLight would be willing to add such an option I suppose is another question...

ehat

Edit: Just pondering this some more. The ideal solution would be something as simple as possible - the more simple it is, the more bLight is likely to implement it. Adding a totally new option as I have proposed may make things too complex. Your solution TSR is simpler - the question becomes then: Can we be sure that the OSD API option is 100% linked to the crashes and visual glitches? If so - and by that I mean that 'option enabled=issues occur, option disabled=issues do not occur' - then we may not really be losing anything by linking the OSD API option to the fsefix bypass as you suggest. To put it more simply, if there is no benefit to having the OSD API option disabled and still having the fsefix code enabled (which my solution would allow, but yours would not), then we don't really lose anything by excluding that combination as an option (i.e. we would not lose anything by having the simpler solution implemented).

(If that makes sense, lol. It's clear in my mind what I want to say, but I'm not sure if I'm actually wording it so people can understand it!)

Edited by ehathgepiurhe, 30 October 2012 - 11:00 AM.
Some more thoughts

[tvholic]

Just curious - why do they need to be added to default.key?

default.key is supposed to contain all the key bindings, so that it can be used as the basis for custom key files.

Regarding the VobSub issue, I am in agreement with TheShadowRunner. I don't run the Install Center, but the first time I run Zoom Player after a new install I get a warning that my VobSub filter is outdated and "possibly unstable". The distinguishing feature of Zoom Player, compared with other media players, has been that it doesn't ship with any codecs/filters, but leaves it up to the user to have the proper filters installed. It's one thing to make certain filters available for users who want them, but it's another to recommend replacing my (1-month-old) mainstream MPC-HC version of VSFilter.dll with your (3-month-old) weirdo xy-VSFilter version, just because it has a higher version number.

[mitko]

4. Finally when pressing the "?" button at Playback > Video > Video Renderer", the information window that details the different renderers specs is so big it cannot be closed! (OK button at the very bottom is hidden) ;;

I will re-open the bug, but I don't think the dev's can fix this fully without ditching the new skinning totally. Firstly, the font size needs to be fixed for each individual skin (It was fixed for Onyx, that is why the bug was closed), and secondly, if you have a resolution below a certain size, this still won't fix the issue either (for example, Onyx HD on my 1200 vertical resolution still has this problem). The bug has been opened and closed so many times it is like a revolving door.

ehat

Edit: The bug for #4 (#339) was only re-opened a few days ago by myself, so nothing to be done for the moment.

I think that the solution is pretty simply - when the [?] button is pressed the information should be shown in a separate scrollable window with fixed size, not using the "MessageBox" like information window. It will probably lose the skinning but after wall this information is part of the options dialog which is not skinned at all and I think that a "normal" window will be more appropriate at this context.

about the madVR FSE issue
I'm not sure I see the increased delay when going to the next file but I think that such kind of changes should be optional and I mean a totally separate option because linking it to the one about the OSD API will be both confusing (no one will ever know it'll affect two unrelated things) and at the same time impossible to use for people like me that like and use the OSD through madVR's API and still didn't experience any issues (at least not for almost an year) when going to the next file in the playlist/folder ... and who like speed improvements