Hello World

[sonicblue]

Hello, I am interested in writing a plugin for the V2.

I wish to create a plugin that will set the video enhancement sharpness setting on a per-resolution basis.

I thought the easiest way of doing this would be to use the autores plugin as a starting template, and modify it to write a value to /proc/stb/vmpeg/0/pep_sharpness instead of setting the video res.

Autores repository:
https://github.com/beyonwiz/enigma2-plu ... resolution

I was wondering how I might build this as a separate plugin and launch it on the V2.

According to Grumpy_Geoff, it seems to be a matter of simply copying the uncompiled files over to the Wiz. However I see there are makefiles which are typically used for compiling the source code - is there a tool chain or SDK I need to get to build the project?

[sonicblue]

After some searching it seems the Wiz runs the Python code as an interpreted language - neat!

I guess all I need to do is drop the files into /usr/lib/enigma2/python/Plugins/Extensions/ and restart the GUI?

[adoxa]

That'll work. If you're on Windows I have a batch file that will generate a package. It uses Cygwin tar, as I had problems with bsdtar (which is the version 10 has). I could try again, if you'd like. You can find the batch file from my plugins at BitBucket. If you're on Linux/macOS you should be able to make a package from scripts supplied by opkg, but maybe one of the Peters can provide more advice on that. You shouldn't need the SDK unless you want to build a native binary (and you'll need Linux to use it).

[prl]

If you're on Linux/macOS you should be able to make a package from scripts supplied by opkg, but maybe one of the Peters can provide more advice on that. You shouldn't need the SDK unless you want to build a native binary (and you'll need Linux to use it).

I don't have opkg installed on my Mac. I copy package source files to the test Beyonwiz, have it compile them by running the plugin, then copy the .pyo files back and use a copy of ipkg-build to make the package from those .pyo files. I have it all packaged into a Makefile, so it's not as inconvenient as it sounds.

I can't remember where I got ipkg-build. Perhaps from the opkg-utils plugin on the Beyonwiz. It's just a shell script.

[sonicblue]

Thanks, but isn't there an easier way? I was thinking something like:

• Tar all the source files using Cygwin

• Send the tar file to V2 using FTP client

• Untar it on the V2 using Telnet

• Launch?

Would this even work?

[peteru]

If you are talking about development workflow...

rsync - available on every install, because it is so useful. Install ssh keys in /home/root/.ssh/authorized_keys and it's trivial.

1. Edit on computer.
2. Push changes with rsync to Beyonwiz.
3. Restart GUI to run new code.

You can put 2. and 3. above in a script that will run rsync with the right arguments and then use ssh to restart the GUI for you.

You only need to copy over the new source files, there is no need to compile python code. Compiling is really just tokenisation and it happens automatically when you have .py files that are newer than .pyo or .pyc files.

[prl]

Adoxa and I were posting about creatng a package.

But yes, for development work I just copy the relevant plugin files to the PVR and restart the GUI.

[sonicblue]

Thanks for the suggestions.

I was a bit overwhelmed and wanted something a bit simpler, so I'm using WinSCP to move the files across because it's small and portable compared to stuff like Cygwin and MinGW. I will then use PuTTY to send commands like restart GUI and read debug lines.

I seem to have hit a roadblock though, I'm trying to get the AutoResolution plugin to show, but haven't been successful.

The AutoResolution plugin appears to be a completely different standalone plugin to the "automatic resolution" setting in [AV Settings] (sidenote: I'm also interested to see if this plugin doesn't suffer the issue described in item 3 of this thread ).

The one I am trying to install looks like this:



It is located at: https://github.com/beyonwiz/enigma2-plu ... resolution

I copied the following files across:



Note: I first tried copying to /Plugins/Extensions, however I noticed in a few of the meta files (__init__.py, makefile.am and plugin_autoresolution.xml) there are path references to Plugins/SystemPlugins.

I then restarted the GUI and noticed Enigma has created optimised .pyo files from the .py files:



I then restarted the GUI again, but still don't have an AutoResolution plugin in the plugins menu.

I'm guessing something is wrong inside the .py files. Perhaps the plugin descriptor is wrong?

Here it is with spacing to make it more legible:

Code: Select all

def Plugins(path, **kwargs):
lst = [

	PluginDescriptor(
	where = [PluginDescriptor.WHERE_SESSIONSTART],
	fnc = autostart
	),		  
	
	PluginDescriptor(
	name="Autoresolution",
	description =_("Autoresolution Switch"),
	where = PluginDescriptor.WHERE_MENU,
	fnc = startSetup
	)
]

if not config.plugins.autoresolution.enable.value
and config.plugins.autoresolution.manual_resolution_ext_menu.value:

lst.append (  
	
	PluginDescriptor(
	name = _("Manual resolution"),
	where = PluginDescriptor.WHERE_EXTENSIONSMENU,
	needsRestart = False,
	fnc = openManualResolution
	)
)
return lst

My understanding of the above: enigma takes multiple descriptors and uses a different "func" depending on the "where" field like so:

-The first descriptor means call autostart() at system start
-The second one means call startSetup() when selecting the plugin from the plugins menu
-The third one means call openManualResolution() when selecting the plugin from the extensions menu

If the above is true, then maybe PluginDescriptor.WHERE_MENU is the wrong syntax, or startSetup() is doing something wrong.

edit: seems WHERE_MENU should be WHERE_PLUGINMENU. The plugin now shows up in the menu but crashes on launch...

[sonicblue]

So the log seems to be showing autores is running:

Line 224: {4148}< 3908.500> [AutoRes] port changed to HDMI
Line 225: {4148}< 3908.500> [AutoRes] mode changed to 1080p
Line 226: {4148}< 3908.502> [AutoRes] default ('1080p', 'default')
Line 227: {4148}< 3908.503> [AutoRes] preferedmodes ['1080i', '720p', '576p', '576i', '480p', '480i', '2160p', ('1080p', 'default')]
Line 373: {4148}< 3909.784> [AutoRes] service changed
Line 445: {4148}< 3910.785> [AutoRes] determineContent

However nothing in Plugins and thus no GUI window.

[sonicblue]

In PuTTY when I want to restart enigma and see printlines for debugging purposes I'm using init 4; sleep 4; enigma2.

But if I terminate the telnet session by closing the PuTTY window, or cancel the telnet command by Ctrl+C in PuTTY, it crashes the Beyonwiz.

[MrQuade]

In PuTTY when I want to restart enigma and see printlines for debugging purposes I'm using init 4; sleep 4; enigma2.

But if I terminate the telnet session by closing the PuTTY window, or cancel the telnet command by Ctrl+C in PuTTY, it crashes the Beyonwiz.

That's because enigma2 was run as a child process to that telnet session.

'init 3' is what you want.

[MrQuade]

btw, I doubt the Autores plugin actually works on the Beyonwiz firmware at all. I remember playing with it a little in the early days of the T3, before the auto resolution options were added to the base firmware.

[sonicblue]

That's because enigma2 was run as a child process to that telnet session.
'init 3' is what you want.
btw, I doubt the Autores plugin actually works on the Beyonwiz firmware at all. I remember playing with it a little in the early days of the T3, before the auto resolution options were added to the base firmware.

Thanks.

Managed to get Autores to appear in the plugins menu by changing it to PluginDescriptor.WHERE_PLUGINMENU, but it crashes on launch. Trying to find out where the relevant log is...

[sonicblue]

{2171}< 299.864> TypeError: startSetup() got an unexpected keyword argument 'callback'

Code: Select all

def startSetup(menuid):
	if getImageDistro() in ('teamblue', 'openhdf'):
		if menuid != "video_menu":
			return [ ]
	else:
		if menuid != "system":
			return [ ]
	return [(_("Autoresolution"), autoresSetup, "autores_setup", None)]

Hmm...

[sonicblue]

Strange that EPGRefresh uses PluginDescriptor.WHERE_MENU and yet appears in the plugins menu.

I guess the AutoResolution plugin must be written for a different version of enigma and must be doing other wrong things. Looks like I'm going to have to start from scratch.

[peteru]

Start with these two:

https://bitbucket.org/beyonwiz/easy-ui- ... deoMode.py
https://bitbucket.org/beyonwiz/easy-ui- ... VSwitch.py

[peteru]

For a plugin that is known to work, look at:

https://bitbucket.org/beyonwiz/easy-ui- ... ins/IceTV/

The development history is on the icetv branch, so you can see how I built the plugin, step by step.

First commit on the branch:

https://bitbucket.org/beyonwiz/easy-ui- ... df3825ab98

[sonicblue]

Thanks peteru, heaps of information there. Starting to get an overall idea of what needs to be done.

[sonicblue]

That's because enigma2 was run as a child process to that telnet session.
'init 3' is what you want.

I notice with init 3 it's not outputting all the print lines. eg. to determine the range of pep_sharpness value I need to look at the output of line 177 of VideoEnhancement.py: print "--> setting sharpness to: %0.8X" % myval but it only shows up in telnet if I use init 4.

edit: oh I need to use init 3 after ctrl+c in PuTTY.
But is there some other way like setting a debug mode that only shows my plugin's debug lines?

[MrQuade]

I'd suggest you output the debug messages to a log file instead, then you can just tail that for live updates.

[Grumpy_Geoff]

-The third one means call openManualResolution() when selecting the plugin from the extensions menu

I know you've now got it appearing in the Plugin menu, but my understanding is the plugin should show when the Extensions popup menu is shown when you press BLUE from live TV.

[sonicblue]

I'd suggest you output the debug messages to a log file instead, then you can just tail that for live updates.

Works great, thank you.

[sonicblue]

After some more testing it seems it will not be possible to achieve a per-resolution sharpness on the V2 due to its sharpness bug where for a given pep_sharpness value it can produce different amounts of actual on-screen sharpness depending on the resolution of the previous video stream being played and other user activity. The only values that appear to be capable of being consistently applied are min (0) and max (10000).

Looking at the log output of VideoEnhancement.py, it appears to be setting the correct hex value every time, so the sharpness bug is probably occurring further on in the chain, perhaps in the Huawei driver which I'm guessing would render it unfixable in the same way the T2's horizontal resolution filtering bug for 576 modes was a driver issue. It would be like asking Microsoft to fix a problem in Nvidia's drivers - not going to happen.

[sonicblue]

I was trying to debug VideoMode.py and noticed it never prints out this line to the log:

Code: Select all

print "[VideoMode] setMode - port: %s, mode: %s" % (config_port, write_mode)

I have autores enabled and tailing the log file when its timer fires and changes the display mode 8 seconds after zapping.

Also I've tried editing VideoMode.py to add more debug lines and then copying it to the V2. After rebooting it gets compiled to a .pyo file, but the [AV Settings] screen becomes broken. Do I need to compile it externally with some special switches?

[prl]

I was trying to debug VideoMode.py and noticed it never prints out this line to the log:

Code: Select all

print "[VideoMode] setMode - port: %s, mode: %s" % (config_port, write_mode)

I have autores enabled and tailing the log file when its timer fires and changes the display mode 8 seconds after zapping.

I'd expect that if VideoChangeDetect() is called and (video_height and video_width and video_pol and video_rate and write_mode and current_mode != write_mode) is True then the line would be printed to the debug log, if debug logging is enabled.

If you want it to print to some other file, you need to make it something like print >>my_debug_fileobj, ...

Also I've tried editing VideoMode.py to add more debug lines and then copying it to the V2. After rebooting it gets compiled to a .pyo file, but the [AV Settings] screen becomes broken.

You may need give more detail than "broken". Are there any exception tracebacks in the debug log file?

Do I need to compile it externally with some special switches?

No. But if you want to see stuff in the system debug log, debug logging must be enabled, and you'll need to restart the GUI twice to ensure that the logging is working. (Twice? Don't ask )

[Grumpy_Geoff]

... debug logging must be enabled, and you'll need to restart the GUI twice to ensure that the logging is working. (Twice? Don't ask )

I thought adoxa eliminated that two-start requirement if you enable debug logging using the UI.

[prl]

... debug logging must be enabled, and you'll need to restart the GUI twice to ensure that the logging is working. (Twice? Don't ask )

I thought adoxa eliminated that two-start requirement if you enable debug logging using the UI.

It doesn't look like it to me. It would require a mkdir in enigma2.sh if the debug log dir isn't there, and the required mkdir isn't in the script.

[Grumpy_Geoff]

... debug logging must be enabled, and you'll need to restart the GUI twice to ensure that the logging is working. (Twice? Don't ask )

I thought adoxa eliminated that two-start requirement if you enable debug logging using the UI.

It doesn't look like it to me. It would require a mkdir in enigma2.sh if the debug log dir isn't there, and the required mkdir isn't in the script.

I meant in the code, not in enigma2.sh, didn't this commit do it? -
"Fix creating the `logs` directory when the settings are closed."
https://bitbucket.org/beyonwiz/easy-ui- ... 50345a878b

[prl]

... debug logging must be enabled, and you'll need to restart the GUI twice to ensure that the logging is working. (Twice? Don't ask )

I thought adoxa eliminated that two-start requirement if you enable debug logging using the UI.

It doesn't look like it to me. It would require a mkdir in enigma2.sh if the debug log dir isn't there, and the required mkdir isn't in the script.

I meant in the code, not in enigma2.sh, didn't this commit do it? -
"Fix creating the `logs` directory when the settings are closed."
https://bitbucket.org/beyonwiz/easy-ui- ... 50345a878b

I didn't think to look there.

[Grumpy_Geoff]

I didn't think to look there.

... and this, though it was 11 months ago

Does the code create a logs directory if you change the log location and there's no logs subdirectory there? If not, you'll need two restarts (or reboots) to enable logging if you change the log location.

Yes, I fixed that, too.

[sonicblue]

I'd expect that if VideoChangeDetect() is called and (video_height and video_width and video_pol and video_rate and write_mode and current_mode != write_mode) is True then the line would be printed to the debug log, if debug logging is enabled.

That's what I expected too, but for some reason it isn't. I have of course enabled logging as I am tailing the log file in real time, which is impossible without logging enabled. The log file is called Enigma2-2020-06-01_10-52-33.log and I'm reading it from /media/hdd/logs.

If that print line from VideoMode.py is not executing, then neither are the lines directly below it, since they are also part of that conditional block:

Code: Select all

f = open("/proc/stb/video/videomode", "w")
f.write(write_mode)
f.close()

In that case I'm left wondering how it's changing the video mode delay seconds after I zap to a different channel, since that conditional is the only place where /proc/stb/video/videomode is written to inside the function called by the delayed eTimer via callback from the iPlayableService events.

The only other places I can see /proc/stb/video/videomode being written to:

AVSwitch.py : InitAVSwitch() -> setConfiguredMode() -> setMode()
AVSwitch.py : hotplug() -> setMode()
VideoMode.py : confirm() -> setMode()
VideoMode.py : apply () -> setMode()

But the above are not part of the auto resolution switching logic.

Even more confusing is these functions inside the same conditional have printlines which do appear in the log delay seconds after VideoChanged():

iAVSwitch.setAspect(config.av.aspect)
iAVSwitch.setWss(config.av.wss)
iAVSwitch.setPolicy43(config.av.policy_43)
iAVSwitch.setPolicy169(config.av.policy_169)

So it seems we're inside the first conditional (if video_height and video_width and video_pol and video_rate:) but not the last one which is the one that actually changes the video mode by writing to /proc/stb/video/videomode.

I'm stumped

You may need give more detail than "broken". Are there any exception tracebacks in the debug log file?

It causes the [AV Settings] GUI to not show any selectable resolutions at all, and toggling the auto res switch does nothing at all. There is nothing in the log file pertaining to exceptions or videomode. Clicking OK on the [AV Settings] menu (which opens the now broken menu) doesn't cause any output to the log file either.

[sonicblue]

[deleted - was looking at the wrong source code]

[peteru]

Are you working with the right source code? Your link points to GitHub, but all development is done on BitBucket.

https://bitbucket.org/beyonwiz/easy-ui-4/

The current code certainly does not have a line with print "[VideoMode] setMode - port: %s, mode: %s" % (config_port, write_mode)

[sonicblue]

Are you working with the right source code? Your link points to GitHub, but all development is done on BitBucket.

Ohhhh noooooo

[sonicblue]

I get it now: /proc/stb/video/videomode is the current HDMI mode, /proc/stb/vmpeg/0/xyres is the current video stream resolution.

When stream res changes, VideoChanged() is called, which starts a timer which calls VideoChangeDetect() after delay.

VideoChangeDetect() then grabs the HDMI mode from /proc/stb/video/videomode and video stream res from /proc/stb/vmpeg/0/xyres , cleans and compares them, and if not equal sets the new HDMI mode by writing to /proc/stb/video/videomode.

Now all I gotta do is add some debug lines so I can see why it's applying the global fixed res on the iPlayableService events before the delayed timer.

[peteru]

Almost. The code only resorts to the /proc values reported by the decoder if the calls to getInfo(iServiceInformation.*) do not provide usable answers.

On the T series those heuristics worked well enough, but I think the U4 and V2 drivers may not have the same driver behaviour. It may be instructional if your debug output reports which value is being returned by which call. You don't want to blame the drivers for dodgy values if you are using whatever the service is reporting. However, it is more likely that you'll discover that the /proc entries contain lies. I'm pretty sure that I saw some video format misidentification issues in early iterations of the V2 drivers. I reported this bug (as well as issues with colour space / format and bad black levels), but I'm not sure if it ever got fixed. The "greys instead of blacks" issue is still there if you leave the colour space / format at the default settings.

[sonicblue]

Cheers Peter, I'm sure you probably saved me some hair pulling

I reported this bug (as well as issues with colour space / format and bad black levels), but I'm not sure if it ever got fixed. The "greys instead of blacks" issue is still there if you leave the colour space / format at the default settings.

I noticed the [HDMI Colorspace] "Auto" actually outputs RGB which can get interpreted by TV's as "full range" and can result in wrong black level. Most TV's nowdays seem to have a manual black level control which you might be able to correct it with. The Wii U had this issue - it only outputted RGB limited range, which is such an oddball format that almost never gets used by anything and so a lot of people thought Wii U just had washed out graphics when it was Nintendo's bad decision to use that weird format which most TV's won't display correctly.

[sonicblue]

I'm having an issue where if I use init 3; sleep 4; enigma2 it kills updates to the system log file.

If I use init 4; sleep 4; enigma2 it updates to the system log file, but many print lines are missing, such as the one from my plugin, but the print lines are visible in the telnet window.

If I go to the V2 and manually select "Restart GUI", everything is fine, a new log file gets created and all print lines are present.

Is it possible to issue the exact same command as above, but from telnet?

Neither init 3; sleep 4; enigma2 or init 4; sleep 4; enigma2 causes the "powered by WizTV" splash screen to appear like "restart gui" does, so I know it must be a different function.

[MrQuade]

Why are you calling enigma2 manually at all? What are you trying to achieve that you can't by just using init to start and stop the system.

[peteru]

First, you don't need the sleep.

There's a bit more to it under the hood, but when simplified, init 3 starts enigma2 and init 4 stops it. The inittab does not run enigma2 directly - instead the script /usr/bin/enigma2.sh is executed. The wrapper script takes care of various things, including log redirection. If you want to start enigma2 manually, you should use the wrapper script unless you have a very specific need to do otherwise and understand all the implication of running enigma2 directly. However, I recommend against that, just use init.

init 4; init 3 should have mostly the same effect as restarting the GUI, but without the benefit of a graceful enigma2 shutdown. The enigma2 process will be killed. That's why you don't see the shutdown screen.

My development system has the power button function reassigned so that short press shows the power menu. I will usually push updates to the target machine and when I'm ready to restart the GUI, I press POWER, then 5. It's quick enough and it allows me to have complete control of when the restart occurs.

[sonicblue]

Why are you calling enigma2 manually at all?

Because that's what this tutorial said to use.

init 4; init 3

Works, thank you.

[MrQuade]

Because that's what this tutorial said to use.

Ok, no worries, I was just confused since I thought you'd solved a similar issue with the same advice earlier.

[prl]

Why are you calling enigma2 manually at all?

Because that's what this tutorial said to use.

Not quite. In one place, to do a quick test, it says:

Ok, if you have installed the Tutorial plugin, start a telnet session to your dreambox
and type in:

Code: Select all

root@dm8000:~# init 4; sleep 4; enigma2

Enigma2 restarts and you can see the enigma2 messages in telnet.
All print commands or error messages of your plugin will be shown there. (also during
enigma2 startup)

But later it says:

To start up enigma2 again:

Code: Select all

root@dm8000:~# init 4; sleep 4; init 3

[peteru]

You need to be a bit selective when using information from the Internet. In particular, it is rare that information from more than a decade ago is still 100% relevant. The fact that the tutorial is based on the original Dreambox environment does not help either. The Open Alliance environment is significantly different. Additionally, the underlying enigma2 implementation details have changed quite a bit and some coding idioms have been replaced with others. If I recall correctly, that particular tutorial was not very helpful. In particular, some of the coding practices appeared to be ill advised. I realise that in the absence of other documentation, this tutorial probably seemed like the best available option.

Based on your experiences, it looks like it would be nice to have some introductory tutorial style documentation for people wishing to hack on Beyonwiz boxes. There's a lot of information here on the forums, but it's not easy to get at all the relevant info. A more appropriate place for this type of documentation may be a BitBucket wiki associated with the repository. Placing the documentation there would allow easy cross referencing to the issues database as well as the code itself.

I enabled the wiki at https://bitbucket.org/beyonwiz/easy-ui-4/wiki/ and at the moment it has full public access. Mainly to facilitate easy edits. If there are any signs of vandalism, I'll have to change the wiki permissions to require all edits to be submitted using pull requests. For now I'll try to keep the barriers to contribution low and enable anyone to edit the wiki.

[sonicblue]

Yeah sorry about that, I'm a total noob at Linux and Python and just Googling things
From now on I'll be learning exclusively from code examples in the Beyonwiz BitBucket repository.

[sonicblue]

I'm currently learning the nightmare known as the config file

Is my current understanding correct that:

config.plugins.myplugin.enabled.value = True # setting is applied, but will be lost if the user reboots

config.plugins.myplugin.enabled.save() # the setting will be written to file and survives a reboot, but only if user reboots gracefully i.e no A/C loss

configfile.save() # forces all system-wide config settings which have had save() called on them to be immediately written to file and will surive any type of reboot

[sonicblue]

So in ConfigList.py there's this:

Code: Select all

	def saveAll(self):
		for x in self["config"].list:
			x[1].save()
		configfile.save()

This seems to imply we need to follow that convention of creating a self["config"].list. Except I can't get it to work:

Code: Select all

class MyPlugin(Screen):	
	def __init__(self, session):			
		config.plugins.myplugin = ConfigSubsection()	
		config.plugins.myplugin.enabled = ConfigYesNo(default = False)		
		self.list = [			
			getConfigListEntry(_("Enable plugin"), config.plugins.myplugin.enabled,
								_("Enables this plugin."))		
		]		
		self["config"].list = self.list  # copied from VideoMode.py

Result:

{3943}< 3087.355> File "/usr/lib/enigma2/python/Plugins/Extensions/MyPlugin/plugin.py", line 98, in __init__
{3943}< 3087.355> self["config"].list = self.list
{3943}< 3087.355> KeyError: 'config'

[prl]

Did you define self["config"] somewhere? As something that has a list attribute?

[sonicblue]

Did you define self["config"] somewhere? As something that has a list attribute?

I thought that's what this was doing:

Code: Select all

self["config"].list = self.list

It seems we have to pass an empty self.list to ConfigListScreen.__init__ and it will create the attribute:

Code: Select all

self.list = []
ConfigListScreen.__init__(self, self.list, session=session)