AVBin is required to decode compressed media

superjoe on 2011/04/18 21:25

I get this message on about 50% of Windows systems that I try to deploy on. I don't see a pattern. I include avbin.dll in my package. I can't figure out why it doesn't work for some people. If I can't figure out why this happens, then I can't depend on pyglet. As convenient as it is to develop with, I've discovered it has some unacceptable flaws when it comes to deploying my application.

(log in to comment)

Comments

adam on 2011/04/18 22:13:

I seem to remember finding that putting avbin.dll in the folder with the game doesn't do anything, but putting it in the Windows system folder (obviously you need to get the user to do this) usually works.

superjoe on 2011/04/18 23:36:

Tried it, no effect.

gcewing on 2011/04/19 01:08:

Can't help you with Windows, but anyone having this problem on Unix should check the permissions on the avbin library. On my MacOSX system, avbin.dylib somehow ended up installed as root with rwx------, which wasn't a lot of use!

Also, digging into the source I discovered that it looks like the "AVBin is required" message can arise for other reasons than not having AVBin, such as encountering a file format that's not understood. So it's possible that your AVBin is actually being found, but something else is going wrong.

superjoe on 2011/04/19 01:34:

Maybe I should try using ogg instead of mp3.

gizmo_thunder on 2011/04/19 10:14:

It seems to work fine with the executable that i made.. 
https://sites.google.com/site/vkgamedev/home/mucap
If you find that this exe works on the systems where your app is failing may be we can start looking for the actual problem :)

tartley on 2011/04/19 13:39:

This is a tricky thing to get right, I agree.

If you take one of the systems on which it does work, then what happens if you remove AVBin.dll from your distribution? Does it still work? (obviously what I'm wondering is whether it works because someone already has avbin installed and available from some other source)

I am convinced that this is fixable, and that there are plenty of people who understand these issues intimately (no doubt many of them on this message board.)

Once we figure it out, we should document it carefully. A good place to do so might be:

http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules

tartley on 2011/04/19 13:41:

I suddently realise that I'm assuming you're distributing using py2exe, even though you didn't mention that. Are you? Distributing to users as source is fraught with peril, since in the general case they are unlikely to have the right version of Python installed and foremost on the path.

superjoe on 2011/04/19 16:58:

gizmo, great idea. Unfortunately I don't have access to the systems where I was getting this problem at the moment. When I get a chance I'll run your test program.

Yes, tartley, this was using py2exe. I got the same error when I deleted avbin.dll entirely. Agreed, it would be wonderful if we could figure it out and document it.

tartley on 2011/04/21 17:15:

I once used a bare install of WindowsXP to investigate the issue of bundling msvcrt dll with py2exe, which seemd to clear up the confusion I had at the time,

I'll see if I can perform similar experiments with avbin.

tartley on 2011/04/21 17:27:

Incidentally, whatever wisdom I discovered from my VM experiments were incorporated into my 'python_project_template' project:

http://code.google.com/p/python-project-template/

I don't yet remember precisely what the above project does with the MS C runtime DLL, other than copy it into the project using setup.py 'data_files'. However, I do remember that before creating this template, my py2exe programs would not run on a bare-bones XP VM, due to missing the C runtime DLL, but using that template, my py2exe programs seem to reliably run on all windows machines I have tried them on.

For the moment, I'm going to try the hypothesis that whatever I do with the microsoft C runtime DLL is what needs to be done with the avbin DLL. (minus the "DLL in a subdir with a manifest" gubbins which the C runtime needs these days)

(Incidentally, on reflection, using 'data_files' to copy the DLL probably means it will break if the project is installed from PyPI, which puts 'data_files' into a different directory than 'python setup.py install' does. More experiments required...)