Mplayer-gtk2.tcz has an error when it starts - ~/.mplayer/subfont.ttf

[bigpcman]

 Mplayer-gtk2.tcz  has error on start - "New face failed. Maybe the font path is wrong. Please supply the text font file ~/.mplayer/subfont.ttf.

Note, if Mplayer-gtk1.tcz  is installed first Mplayer2 works.

[Jason W]

That message comes up when you have no subfonts installed.  There is a symlink in the tcz and tce:

/home/tc/.mplayer/subfont.ttf -> /usr/share/fonts/luxisr.ttf

It uses an already installed ttf font in the base system.  It sounds like the /home/tc/.mplayer/subfont.ttf file has been deleted as to why the error message pops up.  Installing mplayer-gtk1 would restore the subfont.ttf and that is why the message went away after loading mplayer-gtk1.  I just booted with "tinycore base nolocal norestore" and Mplayer-svn-gtk2.tcz does not show that error message and the subfont is installed correctly with the extension.

[bigpcman]

The mplayer2 problem appears to happen when it is installed after emelfm2.tcz and opera.tcz.

[Jason W]

I rebooted (tinycore nolocal norestore base) and installed emelfm2.tcz and the tcz version of Opera and Mplayer still worked ok.  Please give as much info on your setup as you can so we can pinpoint the problem.

[bigpcman]

I see what's happening now. I think this is a general operational problem that can happen in the tinycore extension system. I am using the optional install method for all extensions. I also have backup turned on. It looks like the backup of the system at shutdown saves the state of the system as it relates to the extensions that were loaded at the time. When the system is started back up it restores the system (unless norestore is used) to a state that may be incompatible with the installation of new extensions. I found this to be the case with audacity, gimp2 and Mplayer-2.

This presents an interesting challenge. It looks like the only safe way to use optional install when it involves several extensions is to not use the backup system and restore.

---------------------------
edit: Correction, it's audacious, asunder, gimp2, Mplayer2, opera, flash and emelfm(1&2) that I have had "combinatorial" extension loading problems with. This occurred over several days of loading extensions with many backup and restores.

[^thehatsrule^]

It looks like the backup of the system at shutdown saves the state of the system as it relates to the extensions that were loaded at the time. When the system is started back up it restores the system (unless norestore is used) to a state that may be incompatible with the installation of new extensions.

It backs up and restores files in .filetool.lst, excluding those in .xfiletool.lst

[Jason W]

Basically if you delete a config file that lives in /home/tc and then do a normal backup without editing filetool.lst/xfiletool.lst the files you deleted are not restored.  Many apps create config files in /home/tc even though the extensions themselves do not have files in /home/tc.  Deleting them, doing a backup, and then rebooting is the same as deleting them and rebooting a hard drive install.

I am normally not a fan of putting files in an extension under /home/tc for several reasons, mainly as to not overwrite users own config files in /home/tc. with one included in the extension.  But for Mplayer the subfont file does not overwrite existing configuration and it makes use of a ttf font already in base.

As for extensions that are optionally installed, it does not hurt to have their config files persist across reboots as they will harmlessly sit there waiting to be used when the extension is loaded again.