Change 10244 should fix this.

Observations so far regarding change 10244:
- this is better than it was before where it ALWAYS came up and switched focus
- some conditions (certain types of windows or programs being focused like hitting Win-F then changing tracks) will cause it to show up in the foreground and change focus.
- overall consensus from our team is that if the window is popping up, it's just unacceptable.

Dan, can you think of any other way that would keep the window from ever coming up?  The fix you came up with that fast seems to be a step in the right direction, but there is still bad behavior occurring here.

Subject: Re: 

I would need a reproducable case.

vnc to 10.0.3.26:5900 no auth required

another note:  now that vnc server is installed on this machine the cmd window seems to always come up and steal focus.

Subject: Re: 

Please tell me the *steps* you took to cause it.

I need to verify it independently on another machine.

I don't know why it's constantly doing it now.  There were no steps.  I can give you a list of various things I did, though:
- opened windows media player
- hit Win-F to open the search box
- closed out all of the windows that were running
- installed vnc server

Fixed in change 10271

The method used breaks flac cuesheet gapless playback.

Gordon - are you running as a service, or as an application?

I'm running perl...sometimes as a service, and sometimes from a command prompt to see debug output.  I've never seen the separate dos window open in either circumstance.

Subject: Re:  slimtray.exe: when slim.exe runs in userland a dos window comes up when external decoders are used

Unfortunately if you run SlimServer via SlimTray and set to 'Run at login',
it shows the cmd.exe window when a transcoding process is launched.

The new version of flac, 1.1.3, has the ability to decode a flac to a flac in one pass. For flac transcoding (i.e. for multiple track flac files with cuesheets) this means that we can go from 3 spawned processes (on windows: cmd.exe, flac.exe | flac.exe) to just one. If you install the binaries for flac 1.1.3 to the appropriate folders under server/Bin and then modify convert.conf, you can see that it works:

Code:

flc flc transcode * 
     [flac] -c --totally-silent --compression-level-0 --skip=$START$ --until=$END$ $FILE$

I don't have a slimserver installation that can demonstrate bug 4318 (this bug) but I'm wondering if flac 1.1.3 and the above changes to convert.conf will fix this?

OK, I tested this and it doesn't solve the problem.  But, at least we now have an open source ugly dos window rather than a cmd.exe window.

Dan - looks like the fix to force use of socketwrapper means more people are seeing problems with socketwrapper and AV software.  See: http://forums.slimdevices.com/showthread.php?t=31941&page=5

I've tried before to get hold of the source to Ian Cooke's alternative socketwrapper, but at present all we have is the binary which is hosted on Bryan's site.  I would not recommend slim ships a binary of unknown providence, or really recommends it, so is there another way to resolve this bug using a pipeline?

(In reply to comment #13)
> The new version of flac, 1.1.3, has the ability to decode a flac to a flac in
> one pass. For flac transcoding (i.e. for multiple track flac files with
> cuesheets) this means that we can go from 3 spawned processes (on windows:
> cmd.exe, flac.exe | flac.exe) to just one. If you install the binaries for flac
> 1.1.3 to the appropriate folders under server/Bin and then modify convert.conf,
> you can see that it works:
> Code:
> flc flc transcode * 
>      [flac] -c --totally-silent --compression-level-0 --skip=$START$
> --until=$END$ $FILE$
> I don't have a slimserver installation that can demonstrate bug 4318 (this bug)
> but I'm wondering if flac 1.1.3 and the above changes to convert.conf will fix
> this?

One comment on using this method:  It doesn't always work.  When the flac file contains an ID3v2 tag at the beginning, the native transcoding fails.  There's no good reason why a flac file should have an ID3 tag, but it's relatively common with a simple misconfiguration of EAC to add ID3 tags.  So be careful when using this - it may not fly in the wild.

This is not going to get fixed for 6.5.2.  

So is the fix for this likely to be some change to socketwrapper to magically tell Windows not to display the cmd windows?  Is that the holy grail?

Changed the severity as well.  A 'blocker' is preventing developers from working on the product.  'Critical' indicates the program crashes, not that it looks ugly.

change 12002 includes a new socketwrapper based on Ian Cook's version.  Hopefully this avoids the socketwrapper induced problems.

It is still desireable to avoid using socketwrapper for local transcoding, so I suggest this bug remains open.

moving this ahead as well to look at for 6.5.3

So is this bug open against some new non-socketwrapper scheme for encoding?  Also, do we have a reproducible case for this currently?

I would like to verify that the original reason for this bug fix is still necessary as it would be nice to avoid socketwrapper if possible.  Guess this means building a version of the exe using the original Source.pm and running as "start at login" from slimtray - are dos windows still seen when starting transcoding processes?

change 12224 will reduce the cases when socketwrapper is run.

When running as a service, socketwrapper should only be used for remote streams.  When the server runs as an application (either because start at logon is selected or manually starting on Vista) then socketwrapper is used for trascoding of local files too to avoid the cmd window.

The changes made to Source.pm in svn 12223 now cause socketwrapper to be run when the trunk source code is being run as a Windows service using srvany.exe.  I think this may be the opposite of the intended effect, at least according to the comment in the new code: "Description: this should only use socketwrapper when running as an app."

I assume that this is only a problem when running the source as a service, which, of course, is not the usual state of affairs for Slimserer on Windows.  I'm not sure how slimserver can identify that it is running as a service in this context.

Anyway, reverting back to SVN 12222, transcoding (like playing flacs with embedded cues) works just fine (no ugly dos box) and socketwrapper.exe doesn't run, which is preferable.

The original code was inverted from what I thought was originally intended and documented in the comment - this was what I observed when testing.  Socketwrapper was being run when the server was a service, but not otherwise...

Slim::Utils::Misc::runningAsService() returns 1 when running as a service, so we only want to use socketwrapper when this is not true.

Actually I think the problem is that Slim::Utils::Misc::runningAsService() only returns true when it is running as a server using the PerlSvc api, i.e. the slim.exe is running as a service.  Your method of running as a service via won't be viewed as a service?

Can you use the slim.exe for the service?  Otherwise we need another way of determining if we are running as a service.

Could trunk users try change 12227.

In looking for an api call which would allow us an alternative way to check whether we are running as a service for Gordon, I think I found one which fixes the route cause of this bug without needing to use socketwrapper for transcoding local streams.  It relies on Win32::SetChildShowWindow being able to turn off child windows.

The change is in trunk only at present, but if it works for people I will put it in 6.5.3 as well.

This fix works perfectly for me, again, running the trunk as a service under srvany.exe.  I'll try installing tomorrow's nightly on another windows box and running it in a user, not service context, to make sure SetChildShowWindow has the desired effect.  Thanks!  

Ross, have you had a look at this patch in trunk?  If not, could you?  The goal is to make sure nothing else in the world of transcoding has gotten broken or ugly.

Everything looks great except when I try to play my gaptest M4A files, they just don't play. The player hangs at buffering 0%. C:\program files\slimserver\server\logs\server.log only shows this:

[13:20:57.6054] Slim::Utils::Misc::msg (1152) Warning: [13:20:57.6047] Use of uninitialized value in numeric eq (==) at C:/program files/slimserver/server/Slim/Player/Squeezebox.pm line 861.
[13:21:00.5528] Slim::Utils::Misc::msg (1152) Warning: [13:21:00.5522] Use of uninitialized value in numeric eq (==) at C:/program files/slimserver/server/Slim/Player/Squeezebox.pm line 861.
[13:21:02.5088] Slim::Utils::Misc::msg (1152) Warning: [13:21:02.5081] Use of uninitialized value in numeric eq (==) at C:/program files/slimserver/server/Slim/Player/Squeezebox.pm line 861.
[13:21:04.5628] Slim::Utils::Scanner::scanPathOrURL (91) Finding valid files in: C:\music\MP3
[13:21:04.5637] Slim::Utils::Scanner::scanDirectory (285) About to look for files in C:\music\MP3
[13:21:04.5664] Slim::Utils::Scanner::scanDirectory (286) For files with extensions in: (?i-xsm:\.(?:ape|wma|asf|wax|asx|lnk|wpl|shn|wav|wave|mp3|mp2|m3u|pls|xspf|flc|flac|m4a|mov|m4b|mp4|cue|mp+|mpc|ogg|aif|aiff|lnk)$)
[13:21:04.5901] Slim::Utils::Scanner::scanDirectory (314) Found 17 files in C:\music\MP3
[13:21:26.4018] Slim::Utils::Scanner::scanPathOrURL (91) Finding valid files in: C:\music\M4A
[13:21:26.4028] Slim::Utils::Scanner::scanDirectory (285) About to look for files in C:\music\M4A
[13:21:26.4058] Slim::Utils::Scanner::scanDirectory (286) For files with extensions in: (?i-xsm:\.(?:ape|wma|asf|wax|asx|lnk|wpl|shn|wav|wave|mp3|mp2|m3u|pls|xspf|flc|flac|m4a|mov|m4b|mp4|cue|mp+|mpc|ogg|aif|aiff|lnk)$)
[13:21:26.4319] Slim::Utils::Scanner::scanDirectory (314) Found 17 files in C:\music\M4A

Ross - Not sure that any of those debug lines shows what's wrong.

Could you do the same test on the nightly before 12227 and the one immediately after to prove whether the change is the cause?

D'oh! I didn't have iTunes or quicktime installed. I downloaded and installed Quicktime and it works just fine. 

Should I create another bug to improve the error handling in this situation? While I doubt it will happen often, if someone tries to play an m4a file without iTunes or Quicktime installed, SlimServer doesn't make it clear in the logs or via an error message at all what the problem is. 

Thanks again Steven!

Thanks Ross.  

Added to 6.5 in change 12242.  I hope this means this bug can be closed.

Have you had a chance to look at this, Ross?  Thanks!

I've tried a number of times but haven't seen this since. However, Tomer discovered it and opened a somewhat related bug 5128. 

Should we mark this as fixed with change 12242?

I think we should close this bug as I believe the original problem (dos window when transcoding) is fixed.  

The remaining bug is that socketwrapper can crash in obscure cases - I think we should maintain a separate bug for this, but as we now only use socketwrapper for remote stream transcoding, the impact of this is much less.  Bryan has some proposed code for socketwrapper - but I think this one is less critical for 6.5.3 now.

Perhaps close this one and put Bryan and me down against 5128?