Dreamplex not working with 16.1 major upgrade

mikehere · Post by **mikehere** » Tue Mar 28, 2017 07:52

Hi, has anyone had success using dreamplex with the latest Beyonwiz software upgrade to 16.1?

With the latest 16.1 software upgrade on my T3, the latest Dreamplex version of 2.1.3 downloaded from github does not recognise left or right commands from the remote. However the OK button works which lets me access the Dreamplex settings where left and right from the remote do work. The same behaviour occurs when using the remote on the Beyonwiz Android app.

Has anybody experienced the same behaviour or able to suggest any possible fixes? Thanks

MrQuade · Post by **MrQuade** » Tue Mar 28, 2017 08:58

The version of Dreamplex that is included in the Beyonwiz plugins repository works. Why download the one from GitHub?

The 16.1 firmware did do something strange to the way that Dreamplex checks for package dependencies, so you have to manually install any missing packages via the command line unfortunately.

When you do the "system check" in the Dreamplex plugin, take a note of any missing packages it find, and then open a telnet or SSH session to the Wiz and run

Code: Select all

opkg install <package name>

For each missing package.

MrQuade · Post by **MrQuade** » Tue Mar 28, 2017 09:20

Whoops! Eating humble pie on this one!

I just installed Dreamplex from the Beyonwiz repository myself to check it out and sure enough, the left/right buttons are not working with that version either.

That little bug has snuck in very late in the beta, because this was not a problem when I was testing early in the beta.

Hmm, that will need to be looked into.

mikehere · Post by **mikehere** » Tue Mar 28, 2017 11:46

Thanks MrQuade.

Do you know if there are any issues if I regress the PVR to the previous software version by performing a software upgrade via USB stick to the previous software version?

The family can probably live without the bug fixes and enhancements from v16.1 (even though I can see its an extensive update with a lot of great work put in), but not without plex unfortunately. So I wish to change it back for now until plex is known to work with v16.1 or later.

MrQuade · Post by **MrQuade** » Tue Mar 28, 2017 11:52

mikehere wrote: Do you know if there are any issues if I regress the PVR to the previous software version by performing a software upgrade via USB stick to the previous software version?

The family can probably live without the bug fixes and enhancements from v16.1 (even though I can see its an extensive update with a lot of great work put in), but not without plex unfortunately. So I wish to change it back for now until plex is known to work with v16.1 or later.

There should be no problems at all.
Just don't try to restore any settings that were backed up with the 16.1 version firmware. You can happily restore your settings from the previous 4.4 firmware of course.

In the meantime, I'll have a little dig into what broke and when that happened. It should be something that can be sorted out.

MrQuade · Post by **MrQuade** » Wed Mar 29, 2017 02:07

Well I have tested back through 13 versions of the 16.1 firmware, and have come up with nothing so far.

This is VERY strange. I have installed the 20171011 version of firmware and did not restore my settings, and the left/right problem is still present. This is despite the fact that I was testing Plex some time after that firmware was released, and it was working fine at the time.

I even tried installing Plex v2.0 from the old Wiz v4.4 firmware repository and it is still broken.

I also tried deleting my old /hdd/Dreamplex directory in case there was something odd in there.

I can't quite figure out why it is not working now.

I notice that the clock is also displaying a "???" indication which I don't remember from before. Not sure why that is doing that either.

The only thing I can think of is that at the time, I may have still been using my v4.4 settings backup file. I had restored settings from my old firmware installation and manually fixed up the broken settings that I had found. Perhaps there were some other settings in there that Dreamplex wanted.

Completely confused by this one.

peteru · Post by **peteru** » Wed Mar 29, 2017 10:42

Have you updated the Plex server since last successful test?

MrQuade · Post by **MrQuade** » Wed Mar 29, 2017 11:02

peteru wrote:Have you updated the Plex server since last successful test?

It has been updated since then, bit this issue is a button navigation issue before you attempt to contact the server. In fact I can see that Dreamplex can see my server, but I can't navigate any of the top level menus.

So I installed Plex from a fresh USB install with no configuration, so Dreamplex was not aware of the server at that time. The problem persisted.

I'll try switching off the Plex server and trying again just to see if there is any auto-dscovery happening, but I don't think the Dreamplex client has that capability.

headbutt · Post by **headbutt** » Wed Mar 29, 2017 14:45

Hi I'm having the same issue with the Plex Client after the upgrade where can I download the previous firmware version so I can use Plex again?

MrQuade · Post by **MrQuade** » Wed Mar 29, 2017 14:58

headbutt wrote:where can I download the previous firmware version so I can use Plex again?

From the previous firmware thread here.

prl · Post by **prl** » Wed Mar 29, 2017 14:59

headbutt wrote:Hi I'm having the same issue with the Plex Client after the upgrade where can I download the previous firmware version so I can use Plex again?

You download it from where it was originally posted: New Firmware for all T-Series Models (T2/T3/T4) 17/08/2016.

It's a locked thread, but that just means you can't post there. You can still read it.

Molitov01 · Post by **Molitov01** » Wed Mar 29, 2017 16:27

I have the same problem with the V16.1 upgrade. I installed the Dreamplex plugin from the plugin menu but could not move sideways to the server setting to set it up. I uninstalled it then installed previous one I had on from GitHub, but it does not work now either. Dreamplex always was a bit shaky on this device. Plex works much better on other boxes, that I have seen (even on my iPad) but it was still better than trying to mount shares etc. and waiting, watching the spinner whilst it found the 1500 movies on my server. Is there any better way of accessing my server or a better player/plugin? This update has fixed some other issues I was having so I don't want to regress to the old firmware. My old DP-P2 just had it's 8th birthday and still just - well - works and has not had an update for years.

MrQuade · Post by **MrQuade** » Wed Mar 29, 2017 17:02

I'm genuinely surprised that so many people are using Dreamplex

Anyway, I am logging the T4's activity while using Dreamplex, and all it displays is this:

Code: Select all

{535}<   542.466> KEY: 352 make KEY_OK ('OK',)
{535}<   542.466> [ActionMap] OkCancelActions ok
{535}<   542.496> [List] Setting enableWrapAround no longer supported. Use the skin settings instead.
{535}<   542.498> [Skin] processing screen DPS_MainMenu:
{535}<   542.548> <enigma.eVideoWidget; proxy of <Swig Object of type 'eVideoWidget *' at 0x6e309950> >
{535}<   542.565> [Skin] processing screen SimpleSummary:
{535}<   542.617> [SCREENNAME]  ['DPS_MainMenu_summary', 'SimpleSummary']
{535}<   542.625> [SCREENNAME]  DPS_MainMenu
{535}<   542.796> KEY: 352 break KEY_OK ('OK',)
{535}<   544.958> KEY: 106 make KEY_RIGHT ('RIGHT',)
{535}<   544.958> [ActionMap] DP_MainMenuActions right
{535}<   545.154> KEY: 106 break KEY_RIGHT ('RIGHT',)
{535}<   546.031> KEY: 106 make KEY_RIGHT ('RIGHT',)
{535}<   546.032> [ActionMap] DP_MainMenuActions right
{535}<   546.227> KEY: 106 break KEY_RIGHT ('RIGHT',)
{535}<   548.589> KEY: 105 make KEY_LEFT ('LEFT',)
{535}<   548.589> [ActionMap] DP_MainMenuActions left
{535}<   548.785> KEY: 105 break KEY_LEFT ('LEFT',)
{535}<   550.048> KEY: 105 make KEY_LEFT ('LEFT',)
{535}<   550.048> [ActionMap] DP_MainMenuActions left
{535}<   550.244> KEY: 105 break KEY_LEFT ('LEFT',)
{535}<   553.133> KEY: 174 make KEY_EXIT ('EXIT',)
{535}<   553.133> [ActionMap] DP_MainMenuActions cancel
{535}<   553.135> [Navigation] ignore request to play already running service(1)
{535}<   553.135> [Navigation] ignore request to play already running service(1)
{535}<   553.136> [Navigation] ignore request to play already running service(1)
{535}<   553.137> [Navigation] ignore request to play already running service(1)
{535}<   553.144> [SCREENNAME]  GeneralMenuSummary
{535}<   553.145> [Navigation] ignore request to play already running service(1)
{535}<   553.152> [SCREENNAME]  GeneralMenu
{535}<   553.413> KEY: 174 break KEY_EXIT ('EXIT',)

That's from pressing OK to open the Dreamplex plugin from the T4's main menu. Then pressing RIGHT twice, LEFT twice, then EXIT.

I am not sure if this line means much:
{535}< 542.496>

Setting enableWrapAround no longer supported. Use the skin settings instead.

When i pressed RIGHT and LEFT, the highlighted selection in the Dreamplex main menu should have changed, but it did nothing.

I can actually press OK a few times while in Dreamplex, and access one of my libraries. When browsing the library, I can navigate up and down and also use LEFT and RIGHT to page up and down.

Jase · Post by **Jase** » Sat Apr 01, 2017 00:35

I'm having the exact same problem with DreamPlex now I have updated to 16.1.

I look forward to the fix!

Jas

gwl · Post by **gwl** » Sat Apr 01, 2017 15:50

MrQuade wrote:I'm genuinely surprised that so many people are using Dreamplex

FWIW, add my family to those many people using Dreamplex (essential in our household setup).

Fortunately, I didn't upgrade my T2, only the T4 to 16.1 and consequently encountered the Dreamplex problem with that.

cheers,
gwl

djimenez · Post by **djimenez** » Fri Apr 21, 2017 18:10

Same problem with Dreamplex for us and as many have said we use it lots and very frustrating.

Any news on if this will be fixed?

We will just revert back to the previous version for the moment but would love to hear some news on this.

Thank you
Kind regards
Dawn

MrQuade · Post by **MrQuade** » Fri Apr 21, 2017 18:14

I'm actually a bit stumped on this one.

I reverted back to the first alpha version of 16.1 and started with fresh settings.

I installed the Dreamplex plugin and disconnected from the network to ensure that the plugin wasn't contacting my Plex server in any way.
I still had the same issues, and I simply can't figure out why the plugin used to work when I was first using that initial 16.1 alpha version of firmware.

I did save a copy of the dreamplex plugin that came with the 4.4 series, so I can give that a try with the original 16.1 alpha firmware.

I even tried setting the date back to last September to see if that had anything to do with it as well.

Short of that, I am absolutely stumped as to why I had it working then, and not now.

peteru · Post by **peteru** » Sat Apr 22, 2017 02:20

I had a quick squiz at what could have possibly changed that would impact this code. So far the only things that I found that could, but may not, impact the Dreamplex code are the fixes for bugs #575 and #576, which changed Component.Sources.List

I won't have time to dig into this any deeper. I don't know if prl could be convinced to take a look.

prl · Post by **prl** » Sat Apr 22, 2017 12:01

peteru wrote:I had a quick squiz at what could have possibly changed that would impact this code. So far the only things that I found that could, but may not, impact the Dreamplex code are the fixes for bugs #575 and #576, which changed Component.Sources.List

I won't have time to dig into this any deeper. I don't know if prl could be convinced to take a look.

I can have a look at the changes to Component.Sources.List and at the Dreamplex source (if I can find it), but I don't run a Plex server, so I'd need some help in testing from someone who does.

MrQuade · Post by **MrQuade** » Sat Apr 22, 2017 12:47

prl wrote: I can have a look at the changes to Component.Sources.List and at the Dreamplex source (if I can find it), but I don't run a Plex server, so I'd need some help in testing from someone who does.

The src package is available to download from the Beyonwiz repository.

You shouldn't need a Plex server to solve this particular bug. The main menu of the client plugin simply won't allow you to navigate left or right, so it is fairly trivial to start it up and see if the menu works.

I have a config that allows me to just press OK OK OK OK to get to my media library, and the navigation controls work ok at that level, and I can play media, so it's not compltely stuffed.

Beyond that, I'm not sure what else may be broken though.

prl · Post by **prl** » Sat Apr 22, 2017 13:08

OK, thanks. I'll have a look.

MrQuade · Post by **MrQuade** » Sat Apr 22, 2017 13:34

I posted this earlier, but I think it might be worth re-stating.
When I did have dreamplex working in the 16.1 firmware, I was still running settings from my old 4.4 firmware (with the ftp and Samba config files repaired).

I believe that it was some time after my dreamplex tests, that I did a full settings wipe and started fresh.

I went back to an earlier alpha version of firmware and did restore my old 4.4 settings again, but I still had no luck, so I can't really say that the fact that it worked before was due to the old 4.4 settings at all.

prl · Post by **prl** » Mon Apr 24, 2017 18:06

I've found the cause, and it is related in a roundabout way to the changes I made in the components of a List/StringList/Listbox or List/TemplatedMultiContent/Listbox Source/Converter/Renderer chain. Or, if you prefer, it's related to a bizarre misuse of a List/TemplatedMultiContent/Listbox chain.

It can be worked around by making this change to /usr/lib/enigma2/python/Plugins/Extensions/DreamPlex/skins/default/skin.xml:

Code: Select all

--- a/src/skins/default/skin.xml
+++ b/src/skins/default/skin.xml
@@ -8,7 +8,7 @@
                <widget source="Title" render="Label" transparent="1" zPosition="4" valign="center" position="28,13" size="190,30" font="OpenSans; 18" foregroundColor="#5C5C5C" backgroundColor="#000000" halign="left"/>
 
                <!-- menu -->
-               <widget source="menu" render="Listbox" position="10,232" size="1,1" zPosition="0">
+               <widget source="menu" render="Listbox" position="10,232" size="0,200" zPosition="0">
                        <convert type="TemplatedMultiContent">
                                {"template": [ MultiContentEntryText(pos = (10, 14), size = (390, 40), flags = RT_HALIGN_CENTER, text = 0) ], "fonts": [gFont("OpenSans", 35)], "itemHeight": 50 }
                        </convert>

I.e. change the size of the "menu" widget from 1,1 to 0,200.

It's left as an exercise for the reader to work out why this change fixes the problem

I will contact the author of the DreamPlex plugin and suggest the change. It should not affect other implementations, but I'll try to check it on OpenViX before I contact the author. Alternatively, it could be handled in local Beyonwiz skins, but I don't think that's a good idea.

MrQuade · Post by **MrQuade** » Mon Apr 24, 2017 18:23

Great work

MrQuade · Post by **MrQuade** » Mon Apr 24, 2017 22:26

Oh, another thing. Prl, could you also run the system check tool in the Dreamplex plugin and see if it firstly detects missing dependencies properly and then secondly, manages to install the missing packages.

When I tested this earlier on 16.1 it was unable to install the missing packages that it detected. However, the fact that the plugin was acting so kooky, that problem that I encountered may not have been a real one.

It's just if that bit is broken, and you are already contacting the plugin author, then it might be worth getting that sorted out too.

prl · Post by **prl** » Mon Apr 24, 2017 22:43

MrQuade wrote:Oh, another thing. Prl, could you also run the system check tool in the Dreamplex plugin and see if it firstly detects missing dependencies properly and then secondly, manages to install the missing packages.

I would if I knew how to.

MrQuade wrote:When I tested this earlier on 16.1 it was unable to install the missing packages that it detected. However, the fact that the plugin was acting so kooky, that problem that I encountered may not have been a real one.

It installed and ran (apart from the menu bug) for me without any problem on 20170422.

MrQuade wrote:It's just if that bit is broken, and you are already contacting the plugin author, then it might be worth getting that sorted out too.

I've reconsidered fixing it with a skin hack. That will do for people who can apply it and try out the DreamPlex plugin, but I think I know how it can be fixed within the Beyonwiz code.

MrQuade · Post by **MrQuade** » Mon Apr 24, 2017 23:02

prl wrote:
MrQuade wrote:Oh, another thing. Prl, could you also run the system check tool in the Dreamplex plugin and see if it firstly detects missing dependencies properly and then secondly, manages to install the missing packages.
I would if I knew how to.

I can't navigate there to tell you exactly how to get there myself. But you just have to go into the system settings area, and from the you can run a series of system checks for packages like mjpegtools. You don't need a server to access that feature.

prl wrote: It installed and ran (apart from the menu bug) for me without any problem on 20170422.

Likewise for me on my tests with the alpha. It was only the system check that didn't work properly for me.

peteru · Post by **peteru** » Mon Apr 24, 2017 23:26

As I explained, the system check code is broken by design. That is a completely unrelated [1] issue to the weird way the code uses Lists and breaks navigation.

________________________________

[1] Except perhaps by authorship of the code.

MrQuade · Post by **MrQuade** » Mon Apr 24, 2017 23:30

Ok, thanks for the clarification

So it's most likely still broken. I was just hoping that prl could bring it up with the author while he was getting in contact.

peteru · Post by **peteru** » Tue Apr 25, 2017 00:39

I'm not sure if there's going to be much success from trying to get the author to do any work on the Dreamplex plugin. Last time I looked, the upstream repository seemed to indicate that the project has been abandoned or at least put on the back burner.

MrQuade · Post by **MrQuade** » Tue Apr 25, 2017 01:15

Interesting.

I applied the fix myself to have a look, and the main menus can now be navigated. I ran the Systemcheck under System, and indeed as expected and warned by PeterU, it is still broken (by design

).

The same navigation bug is present when you navigate down into your server (which prl would have been unable to do). When you go into your server, you can select from one of your media categories "TV" , "Movies", "Music", and then below that, you get your Libraries, and then titles, genres, etc.

None of the menus below the Server level can be navigated, much like the main menu. Applying the same trick here did the trick:

Code: Select all

        <screen name="DPS_ServerMenu" position="0,0" size="1280,720" title=" " backgroundColor="#ffffffff" flags="wfNoBorder">
                <!-- background -->
                <ePixmap pixmap="/usr/lib/enigma2/python/Plugins/Extensions/DreamPlex/skins/default/images/background-fs8.png" position="0,0" zPosition="-2" size="1280,720" $

                <!-- title -->
                <widget source="Title" render="Label" transparent="1" zPosition="4" valign="center" position="21,12" size="190,30" font="OpenSans; 18" foregroundColor="#5C5C$

                <!-- menu -->
-               <widget source="menu" render="Listbox" position="10,232" size="1,1" zPosition="0">
+               <widget source="menu" render="Listbox" position="10,232" size="0,200" zPosition="0">
                        <convert type="TemplatedMultiContent">
                                {"template": [ MultiContentEntryText(pos = (10, 14), size = (390, 40), flags = RT_HALIGN_CENTER, text = 0) ], "fonts": [gFont("OpenSans", 35)$
                        </convert>
                </widget>

Also, the orange "???" in the title bar is supposed to show the current time I think. Probably broken because "global.CurrentTime" is not a thing it can interpret now?

Code: Select all

                <!-- clock -->
                <widget source="global.CurrentTime" render="Label" position="920,13" size="169,30" zPosition="4" font="OpenSans; 18" halign="left" foregroundColor="#e69405" $
                        <convert type="ClockToText">default</convert>
                </widget>
                <widget source="global.CurrentTime" render="Label" position="830,13" size="390,30" zPosition="4" font="OpenSans; 18" halign="right" foregroundColor="#5C5C5C"$
                        <convert type="ClockToText">Date</convert>

prl · Post by **prl** » Tue Apr 25, 2017 09:58

MrQuade wrote:
prl wrote:
MrQuade wrote:Oh, another thing. Prl, could you also run the system check tool in the Dreamplex plugin and see if it firstly detects missing dependencies properly and then secondly, manages to install the missing packages.
I would if I knew how to.
I can't navigate there to tell you exactly how to get there myself. But you just have to go into the system settings area, and from the you can run a series of system checks for packages like mjpegtools. You don't need a server to access that feature.
...

Sorry, I didn't read your post properly. I assumed that the system checks you meant were the syntax checks that peteru is now applying to Python files in the new toolchain.

I'll give it a go, but as peteru said later, the checks seem to be broken.

prl · Post by **prl** » Tue Apr 25, 2017 10:11

MrQuade wrote:... The same navigation bug is present when you navigate down into your server (which prl would have been unable to do). When you go into your server, you can select from one of your media categories "TV" , "Movies", "Music", and then below that, you get your Libraries, and then titles, genres, etc.

None of the menus below the Server level can be navigated, much like the main menu. Applying the same trick here did the trick:
...

That, and peteru's comment about the DreamPlex code now being pretty much abandoned, reinforce my decision to fix the problem in the Beyonwiz code rather than by skin hacks. The DreamPlex code appears to be using the List/TemplatedMultiContent/Listbox chain to just do modulo arithmetic on the length of a list.

MrQuade wrote:Also, the orange "???" in the title bar is supposed to show the current time I think. Probably broken because "global.CurrentTime" is not a thing it can interpret now?
...

The problem isn't with "global.CurrentTime", but with a small change in the default behaviour of the ClockToText converter introduced in IanSav's huge time format effort. Before that, the "Default" clock format would be used if there was no conversion format specified or if an unrecognised format was given. The new code uses Default if there is no clock format specified, but "???" if an unrecognised one is used. The DreamPlex skin uses the unrecognised clock format "default" (rather than "Default").

MrQuade · Post by **MrQuade** » Tue Apr 25, 2017 10:20

prl wrote: The problem isn't with "global.CurrentTime", but with a small change in the default behaviour of the ClockToText converter introduced in IanSav's huge time format effort. Before that, the "Default" clock format would be used if there was no conversion format specified or if an unrecognised format was given. The new code uses Default if there is no clock format specified, but "???" if an unrecognised one is used. The DreamPlex skin uses the unrecognised clock format "default" (rather than "Default").

I suspected that at first, but when I went back to test the plugin with the original alpha firmware, the ??? was still there, and the original alpha predates IanSav's date/time format changes.

prl · Post by **prl** » Tue Apr 25, 2017 11:01

MrQuade wrote:
prl wrote: The problem isn't with "global.CurrentTime", but with a small change in the default behaviour of the ClockToText converter introduced in IanSav's huge time format effort. Before that, the "Default" clock format would be used if there was no conversion format specified or if an unrecognised format was given. The new code uses Default if there is no clock format specified, but "???" if an unrecognised one is used. The DreamPlex skin uses the unrecognised clock format "default" (rather than "Default").
I suspected that at first, but when I went back to test the plugin with the original alpha firmware, the ??? was still there, and the original alpha predates IanSav's date/time format changes.

I may well have mistaken the point at which the change took place. I was looking at the log of diffs on the converter.

prl · Post by **prl** » Tue Apr 25, 2017 13:27

I've fixed the horizontal menu problem in DreamPlex by changing Sources.List so that it falls back to the old (broken) way that it did up/down/pageUp/pageDown if the height of the renderer is so small that the normal move methods do nothing. If the renderer is a sensible height, it works in the way I intended it to work, especially paging correctly.

I've also made it so that Source.List correctly overrides the skin setting of enableWrapAround if the optional enableWrapAround is set in Sources.List.__init__().

However, the renderer's wraparound remains broken. Its default in the Renderer.ListBox is True, but the skin can only set wraparound to True, it can't set it back to False (i.e. the widget attributes enableWrapAround="1" and enableWrapAround="0" both set wraparound to enabled

)

I'll have a look at fixing up the clock from within the Beyonwiz code, too.

As for the Dreamplex system checks,

Check for gst-plugin-fragmented if you are using OE16: offers to install gst-plugin-fragmented plugin.
Check for gst-plugins-bad-fragmented if you are using OE20: offers to install gst-plugins-bad-fragmented, but that's presumably not the one that would be wanted.
Check mjpegtools intallation[sic] data: offers to install mjpegtools plugin.
Check python imaging installation data: shows opkg info data for python-imaging.
Check python textutils installation data: shows opkg info data for python-textutils.
Check curl installation data: offers to install curl plugin.

I didn't try to install any of the suggested packages. I'm not sure whether the above is broken or not. The Beyonwiz feed doesn't seem to know anything about gst-plugin-fragmented (or gst-plugins-bad-fragmented). The mjpegtools and curl packages are available for installation.

I'm getting thoroughly sick of the amount of time the forum software's anti-code-injection protection makes me waste whenever I try to post anything that's the least bit technical. Apparently one's not allowed to mention the data, nor the curl.

IanSav · Post by **IanSav** » Tue Apr 25, 2017 13:35

Hi Guys,

prl wrote:
MrQuade wrote:
prl wrote: The problem isn't with "global.CurrentTime", but with a small change in the default behaviour of the ClockToText converter introduced in IanSav's huge time format effort. Before that, the "Default" clock format would be used if there was no conversion format specified or if an unrecognised format was given. The new code uses Default if there is no clock format specified, but "???" if an unrecognised one is used. The DreamPlex skin uses the unrecognised clock format "default" (rather than "Default").
I suspected that at first, but when I went back to test the plugin with the original alpha firmware, the ??? was still there, and the original alpha predates IanSav's date/time format changes.
I may well have mistaken the point at which the change took place. I was looking at the log of diffs on the converter.

This is an error in the DreamPlex skin.

The ClockToText converter has always displayed "???" for any invalid conversions. This behaviour was not changed by my code refactor. The error results were a specific path of investigation taken by the code reviewers. In this case "default" is an invalid conversion and "???" is the appropriate output.

Mind you, I don't know why we can't do the token matching in a case insensitive way. During the refactor my suggestion for this was rejected because it would have been a change to the function of the code.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Tue Apr 25, 2017 13:40

prl wrote: As for the Dreamplex system checks,

Check for gst-plugin-fragmented if you are using OE16: offers to install gst-plugin-fragmented plugin.
Check for gst-plugins-bad-fragmented if you are using OE20: offers to install gst-plugins-bad-fragmented, but that's presumably not the one that would be wanted.
Check mjpegtools intallation[sic] data: offers to install mjpegtools plugin.
Check python imaging installation data: shows opkg info data for python-imaging.
Check python textutils installation data: shows opkg info data for python-textutils.
Check curl installation data: offers to install curl plugin.

I didn't try to install any of the suggested packages. I'm not sure whether the above is broken or not.

Yes, the checks themselves work, it is the installation part that fails.

prl · Post by **prl** » Tue Apr 25, 2017 13:44

Bug #586: Horizontal menus in DreamPlex stuck

prl · Post by **prl** » Tue Apr 25, 2017 14:00

IanSav wrote:Hi Guys,
prl wrote:
MrQuade wrote:
prl wrote: The problem isn't with "global.CurrentTime", but with a small change in the default behaviour of the ClockToText converter introduced in IanSav's huge time format effort. Before that, the "Default" clock format would be used if there was no conversion format specified or if an unrecognised format was given. The new code uses Default if there is no clock format specified, but "???" if an unrecognised one is used. The DreamPlex skin uses the unrecognised clock format "default" (rather than "Default").
I suspected that at first, but when I went back to test the plugin with the original alpha firmware, the ??? was still there, and the original alpha predates IanSav's date/time format changes.
I may well have mistaken the point at which the change took place. I was looking at the log of diffs on the converter.
This is an error in the DreamPlex skin.

The ClockToText converter has always displayed "???" for any invalid conversions. This behaviour was not changed by my code refactor. The error results were a specific path of investigation taken by the code reviewers. In this case "default" is an invalid conversion and "???" is the appropriate output.

Mind you, I don't know why we can't do the token matching in a case insensitive way. During the refactor my suggestion for this was rejected because it would have been a change to the function of the code.

Regards,
Ian.

This is the ClockToText converter conversion type setting code from commit 5b7b4bf, which is, as far as I can tell, the last commit before the major changes:

Code: Select all

                if type == "WithSeconds":
                        self.type = self.WITH_SECONDS
                elif type == "InMinutes":
                        self.type = self.IN_MINUTES
                elif type == "Date":
                        self.type = self.DATE
                elif type == "AsLength":
                        self.type = self.AS_LENGTH
                elif type == "AsLengthHours":
                        self.type = self.AS_LENGTHHOURS
                elif type == "AsLengthSeconds":
                        self.type = self.AS_LENGTHSECONDS
                elif type == "Timestamp":
                        self.type = self.TIMESTAMP
                elif type == "Full":
                        self.type = self.FULL
                elif type == "ShortDate":
                        self.type = self.SHORT_DATE
                elif type == "LongDate":
                        self.type = self.LONG_DATE
                elif type == "FullDate":
                        self.type = self.FULL_DATE
                elif type == "VFD":
                        self.type = self.VFD
                elif "Format" in type:
                        self.type = self.FORMAT
                        self.fmt_string = type[7:]
                else:
                        self.type = self.DEFAULT

The conversion type will be set to self.DEFAULT if there is no type set (empty string), or if the type is unrecognised. There isn't even a specific default format name, ether as "Default" or "default", and both would have used the default format.

I agree that ideally the DreamPlex code should be fixed, but as peteru says, it appears to have been abandoned. The old ClockToText code would have displayed the default HH:MM time for the "default" conversion type that DreamPlex used. Curiously, the DreamPlex skin does use "Default" in one ClockToText converter; elsewhere it uses "default" whenever a HH:MM conversion is wanted.

prl · Post by **prl** » Tue Apr 25, 2017 14:21

prl wrote:Bug #586: Horizontal menus in DreamPlex stuck

Fix submitted. And ugly it is, too.

IanSav · Post by **IanSav** » Tue Apr 25, 2017 14:30

Hi Prl,

prl wrote:I agree that ideally the DreamPlex code should be fixed, but as peteru says, it appears to have been abandoned. The old ClockToText code would have displayed the default HH:MM time for the "default" conversion type that DreamPlex used. Curiously, the DreamPlex skin does use "Default" in one ClockToText converter; elsewhere it uses "default" whenever a HH:MM conversion is wanted.

I note that Rossi appears to have updated DreamPlex since it was apparently abandoned. I will try and file a pull request with the corrections and see what happens.

I have also added a comment on the Plex forums to ask that Plex adopt the DreamPlex plugin and bring it up to date for all Enigma2 users.

Regards,
Ian.

IanSav · Post by **IanSav** » Tue Apr 25, 2017 15:02

Hi,

Pull requests #321 and #322 filed to correct "default" error in DreamPlex skins. Rossi has been alerted to the submissions.

Regards,
Ian.

prl · Post by **prl** » Tue Apr 25, 2017 15:54

I did a quick scan through the enigma2-plugins source, and there are a few inventive time conversion formats in there.

I found:
LocaleKurz:
LocaleLang:
InStunden

(locale short, locale long and in hours).

They were in aihdcontroler and valixdcontrol. Must have seemed a good idea at the time to someone.

IanSav · Post by **IanSav** » Tue Apr 25, 2017 15:59

Hi Prl,

prl wrote:I did a quick scan through the enigma2-plugins source, and there are a few inventive time conversion formats in there.

I found:
LocaleKurz:
LocaleLang:
InStunden

(locale short, locale long and in hours).

They were in aihdcontroler and valixdcontrol. Must have seemed a good idea at the time to someone.

They must never have followed your advice to read the source code.

Regards,
Ian.

IanSav · Post by **IanSav** » Tue Apr 25, 2017 16:04

Hi Prl,

Rossi has agreed to apply the skin fixes for DreamPlex.

If you want any code fixes or updates applied to DreamPlex then try creating pull requests against Don's repository and I will ask Rossi to apply them as well.

Regards,
Ian.

prl · Post by **prl** » Wed Apr 26, 2017 12:09

I may have a look at the use of the List/TemplateMultiContent/Listbox chain with a view to replacing it with some arithmetic.

gwl · Post by **gwl** » Wed Apr 26, 2017 17:19

Many thanks Team for your persistence in making DreamPlex into a workable solution!

Your continued efforts are very much appreciated. Let's hope Plex take Enigma2 under their wing too.

cheers,

gwl

IanSav · Post by **IanSav** » Thu Apr 27, 2017 10:39

Hi,

The skin corrections for DreamPlex have been merged.

@Prl: Rossi, in the OpenViX team, is happy to accept corrections to the DreamPlex code. There are a number of OpenViX users who use Plex and would love to have DreamPlex fixed/maintained.

Regards,
Ian.

About the Forum

Join us