Failed to open video file CREDITS.SMK: The specified procedu

[krs]

I keep getting the following:

23:55:32 INFO global [25c] - Initialization of VCMI (together): 55724
23:55:32 TRACE global [c38] - Loading music file Music/MainMenu
23:55:32 TRACE global [c38] - Playing music file Music/MainMenu
23:55:32 ERROR global [c38] - bink failed to open CREDITS.SMK
23:55:32 ERROR global [c38] - Error 127 encountered!
23:55:32 ERROR global [c38] - Error: The specified procedure could not be found.

23:55:32 WARN global [c38] - Failed to open video file CREDITS.SMK: The specified procedure could not be found.

[Tow]

Are the smackw32.dll and binkw32.dll present next to the VCMI executables?

[krs]

Yes. And other video files are played. Like 3DO intro or winning battle video.

It fails on binkOpen with a valid file handle. Could my credits file be corrupted?

bool CBIKHandler::open(std::string name)
{
	hBinkFile = CreateFileA
	(
		name.c_str(),				// file name
		GENERIC_READ,						// access mode
		FILE_SHARE_READ,	// share mode
		NULL,								// Security Descriptor
		OPEN_EXISTING,						// how to create
		FILE_ATTRIBUTE_NORMAL,//FILE_FLAG_SEQUENTIAL_SCAN,			// file attributes
		0								// handle to template file
	);

	if(hBinkFile == INVALID_HANDLE_VALUE)
	{
        logGlobal->errorStream() << "BIK handler: failed to open " << name;
		goto checkErrorAndClean;
	}
	//GCC wants scope of waveout to dont cross labels/swith/goto
    {
		void *waveout = GetProcAddress(dll,"_BinkOpenWaveOut@4");
		if(waveout)
			binkSetSoundSystem(waveout,NULL);

    }

	hBink = binkOpen(hBinkFile, 0x8a800000);
	if(!hBink)
	{
        logGlobal->errorStream() << "bink failed to open " << name;

[Tow]

Perhaps. Do you have a non-standard credits.smk video?
There was similar report bugs.vcmi.eu/view.php?id=1070 though it was a crash rather than graceful failure.

[krs]

Perhaps. Do you have a non-standard credits.smk video?

I do not have it in my Original H3 folder. And I do not recall moving it to VCMI (it is not listed as needed in the wiki).

As I figure it, an “empty” file is created by the above code if the file does not exist. (I am on Windows).

[Tow]

As I figure it, an “empty” file is created by the above code if the file does not exist. (I am on Windows).

It is not created. Function is called CreateFile but when given the “OPEN_EXISTING” flag it opens only existing files and fails otherwise. (cf msdn.microsoft.com/en-us/library … 85%29.aspx )

I do not have it in my Original H3 folder. And I do not recall moving it to VCMI (it is not listed as needed in the wiki).

Original H3 does not store any videos in the game fodler.
VCMI video works like that: the video file is extracted from VIDEO.VID to the game folder, then opened, played, closed and deleted.
There’s one more thing that may go wrong. If VCMI doesn’t have privilege to write into game folder, this will fail as well. You can try running it with admin rights and if there is any difference.

[krs]

I would say there are enough privileges since a file credits.smk is created (and never deleted).

Nevertheless, I ran the client as admin as you suggested but got the same errors in log.

[gotar]

VCMI video works like that: the video file is extracted from VIDEO.VID to the game folder, then opened, played, closed and deleted.

It should go then into $TMPDIR (falling back to /tmp). Otherwise you risk many different problems like exceeding quota. Note that /tmp is often mounted as tmpfs so you save real I/Os.

[Tow]

I would say there are enough privileges since a file credits.smk is created (and never deleted).

Can you copy the credits.smk file as it is when VCMI attempts to open it with Smack player and upload somewhere?

It should go then into $TMPDIR (falling back to /tmp).

There’s no /tmp, the code is windows specific. Though you are right, appropriate temporary directory should be used (boost filesystem had something to portably find them).
Still, I am not eager to do anything with current video player because I’d like to get rid of it altogether and use ffmpeg.

The issue is bigger — VCMI may be put in a place where files cannot be created. We need an option to allow storing logs, config settings and similar in a user directory. As #1288 shows, we should also do something about non-ascii filenames. So much to do…
[Patches are welcomed. :D]

[krs]

Link to credits.smk

[Ivan]

The issue is bigger — VCMI may be put in a place where files cannot be created.

I think it can be fixed with 1-2 API calls - VCMIDirs::localPath() returns data path on Win and correct user directory on other platforms.

Replacing it with proper detection of user directory should fix this. Although may be broken by #1288 if user name has non-ascii chars.

[gotar]

It should go then into $TMPDIR (falling back to /tmp).

There’s no /tmp, the code is windows specific. Though you are right, appropriate temporary directory should be used (boost filesystem had something to portably find them).

I believe I’ve seen some \Windows\Temporary[whatever] - there is GetTempPath and you are referring to generic temp_directory_path.

Talk about paths: $HOME/.vcmi is not the best choice as well - there is XDG Base Directory Specification that encourages you to use $XDG_{CACHE,CONFIG,DATA}_HOME with $HOME/.{cache,config,local/share} fallback to reduce dotfiles mess in $HOME. There is plenty of projects that follow this spec and this would be nice if VCMI make use of these directories as well - it makes easier to do backups (entire configuration and all data files in two directories) and cleanups (one $HOME-wide directory with all the caches).

Although may be broken by #1288 if user name has non-ascii chars.

As long as it goes for UNIX (Mac, Linux), POSIX forbids usage of not portable characters.

[Ivan]

XDG Base Directory Specification that encourages you to use $XDG_{CACHE,CONFIG,DATA}_HOME with $HOME/.{cache,config,local/share} fallback to reduce dotfiles mess in $HOME.

I know about that. Although at this point I don’t like the idea of splitting user data between multiple locations. Current approach is simpler for users (no separate locations for logs, configs, saves and mods).

Perhaps I’ll do the split when launcher will be ready (with functionality like “Open logs/savegames/mods directory”)

As long as it goes for UNIX (Mac, Linux), POSIX forbids usage of not portable characters.

That bug does not affects Linux (and probably Mac) so non-ascii chars are not a problem here but still good to know

[gotar]

XDG Base Directory Specification that encourages you to use $XDG_{CACHE,CONFIG,DATA}_HOME

I know about that. Although at this point I don’t like the idea of splitting user data between multiple locations. Current approach is simpler for users (no separate locations for logs, configs, saves and mods).

Perhaps I’ll do the split when launcher will be ready (with functionality like “Open logs/savegames/mods directory”)

Consider using XDG_CONFIG_HOME until then - even with all in single directory (mods/jsons might be configuration, why not?), it would be better not to trash $HOME directly.

[Ivan]

Main issue that I’d like to avoid is moving anything multiple times. Especially considering that currently vcmibuilder installs all H3 data into ~/.vcmi. This means that there has to be some mechanism to inform user on directory changes or move all data automatically.

And my plan right now is to make launcher usable by next release along with XDG changes. So most of our users will get these changes in next release, no matter when I will actually implement this - right now or in 2 months.