23 replies to this topic

[ashlee24]

Hi,

 

Does anyone know why the autobouquet maker plugin doesn't download from the plugins menu on PLI 6.0 image?? 

 

It comes up with http/1.1 404 not found

 

Many thanks

Edited by ashlee24, 5 December 2017 - 01:31.

[WanWizard]

Which box? And you're not running an old release candidate by any chance?

[Dimmie]

It does download and install, but it doesn't work allright since it is an old version. Autobouquetsmaker needs to be version 2.9 to work fine.

Also in the 6.1 RC the old outdated version is still in the feed.

[littlesat]

What and why doesn’t this ‘monster’ work anymore?

Edited by littlesat, 5 December 2017 - 07:52.

[ashlee24]

Hi,

 

Thanks for the reply, so do I need to install the latest version of Pli to my zgemma h2 star??

Is there no plugin IPK file I can in install manually that will work on PLI image??

 

Any links if there is please

 

Thanks

[WanWizard]

What and why doesn’t this ‘monster’ work anymore?

 

Because they have "data" in the code, so you need a plugin update every time something changes in the data.

[WanWizard]

It does download and install, but it doesn't work allright since it is an old version. Autobouquetsmaker needs to be version 2.9 to work fine.

Also in the 6.1 RC the old outdated version is still in the feed.

 

Bummer, I've updated the 4-release and 6.0-release feeds a few days ago, but now see I haven't pushed the 6.0 change. I'll see if I can update 6.1-rc as well.

[WanWizard]

New 6.0-release build is started, 6.1-rc will be updated in tonights regular build.

[Dimmie]

Nice

[Abu Baniaz]

 

What and why doesn’t this ‘monster’ work anymore?

 
Because they have "data" in the code, so you need a plugin update every time something changes in the data.

 

You deliberately keep posting incorrect and false information.

For anybody wanting to hear the other side of the coin....

 

The channel data is acquired from the stream. Nothing is downloaded from any website *.*

Yes we add some hacks here and there to rename move/exclude channels.

The tuning data is in the xml file for the providers. From time to time, these change. Nobody is in charge of these.

We created a function to update the config files so that people can update the provider files without needing an updated version of the plugin.

The plugin is continually improved. When changes to provider files require changes to other files within the plugin, we increase the version number so that people cannot update the provider files using the GUI and cause it to crash. An example is adding an extra variable or removing them. One such example is the removal of certain tuning parameters that were in essence automatic. When we were ready to remove the details from the provider files, we increased the version number so that people who did not have the value in the xml file would not have a crash.

 

Some changes can be made to the provider files, but not cause crashes, even though other python files changes are required to fully benefit. We don't force the version change in such cases. Why inconvenience users? One such example is forcing flags in lamedb. As you are aware, the ITV channel names are mostly the same. The previous renames only applied names in the the bouquets, not the service list.

 

The renames were on the Sky one, but not Freesat. We added them as well as the flags. So, any Freesat users who update the config files, but don't have the latest python files, won't benefit. But they won't crash.

 

https://github.com/o...1ee325a80a07f94

 

The OE-A bitbake has a dependency on Enigma2. This dependency is not needed. Installing it also updates Enigma2. Building the plugin builds Enigma2 too. Despite numerous attempts to convince my collaborators otherwise, they won't agree to removing it. You can only insatll this on Enigma2 they say!

 

The standlone versions I used to post used to have the dependency removed. Using opkg-tools, I used to unbuild them, edit the control file and remove dependency, rebuild it. Recent changes mean I can no longer use opkg-tools. Despite numerous requests, nobody has provided and idiot's guide on how to do this. I tried modifying the bitbake file and building a shareable one. I was unsuccessful. My abilities do not stretch that far.

 

Please feel free to amend your bitbake file so that it does not depend on E2 and is architecture based instead of machine based.

 

I also asked Andy to edit the bitbake file so that it was architecture based instead of machine based so that sharing it would be easier. The fact that PLi appear to want to peg their version to an old one so taht they can continue bleating about how hacky and horrible the plugin is, led to "no point banging head against brick wall" attitude, so we left it.

 

The only way around this is to have a way of  downloading a pre-compiled version. In that case, why build the plugin when you build an image?  Just have a script to download the latest version.

 

As above mention above, the version number does not tell the whole story.  There could be other changes that went in after the version increase. Plugin will still work unless provider tuning details change.

 

I tried to ask you to remove the plugin from your servers so that people do not have the issue of version on plugin server forcing a downgrade, you refused. I don't see why we should have come begging and grovelling to you to increase the build.

 

Anybody wanting latest ABM can install OpenATV, download the plugin from there and save it. Flash PLi back and install it. They do nightly builds and will always have version with latest changes.

 

opkg download enigma2-plugin-systemplugins-autobouquetsmaker

 

*.* The only download that is done is if someone has added the Custom mix file, these are not part of the plugin, but addons. If people enable the option to fetch the mix file before running ABM, then it will try to download before running. I am not sure if this is what the OP was referring to. He definitely messed up the title because AutoBouquets and AutoBouquetsMaker are different plugins

[Rob van der Does]

The tuning data is in the xml file for the providers. From time to time, these change. Nobody is in charge of these.

Just as this data is present in PLi's FastScan.

[littlesat]

The biggest problem I have with this plugin that it is hacking the lamedb and userbouquets and then reload these bouquets instead of 'directly' creating the bouquets and add channels to the lamedb via e2... (please let me know if I make a mistake here).

 

Also the .so that is 'playing'' dvbsnoop to parse the data streams.The approach has a 'hacky' style.

 

When implemented such .so t would be better to have the .so code added to E2 with some universal syntax around it so you can use it in python anywhere and not only for ABM.

 

I also do not like the exception.s.. Reading a provider list and then rename and/or remove services.... why? Having python code in xml is actually not done (I also don't like it to have it in skins)

 

However acutually I think it was better that FastScan was extended with these extras. This means most of the parcing code has to be done in cpp. And now I think I get to the point. Maybe the creators of ABM did not get any help from someone who can do the cpp part for them.

 

But when I read this thread we're not trying to get it better. It sounds like 'we' go in offend mode again...

[Abu Baniaz]

The two of you are always having snide swipes at the plugin. It really does not achieve anything. If you want to make it better, please contribute to the code. It is opensource. Links to it have been posted in response to several of your posts claiming this plugin is rubbish/hacky.

 

Please explain how using code to add flags in lamedb is "hacking". The code has been in PLI since before 2005. If anybody used a settings editor to do the same, would it be called hacking?

 

With regards to removing services from provider list, if you cant receive the services, e.g you don't have a dis for it, why is it bad to give the user option to exclude them?

So removing the (28.2) and (19.2) in names is bad? What happens when you do an E2 scan? The names change! Is Enigma2 now being evil against Fastscan? Please check the BAT data for the name of "Arirang TV HD" on 28.2. Why is Enigma2 so hacky that it changes this name?

 

You keep mentioning Fastscan and Cablescan in your offensive modes. Fastscan only works for M7 group providers. Cablescan does not work in the UK.

Please come out of your offense mode and enter the collaborative mode. If you want to add the ABM code to them, please do so.  If you want to add to ABM code and make it better, please do so. If you want to add ABM features to E2, please do so. Your expertise will be beneficial and appreciated.

Edited by Abu Baniaz, 6 December 2017 - 09:28.

[littlesat]

If I had sees of time and direct profit I already did it... As long someone does not find the time and willing to make it better we have to live with ABM as it is now.... .... I guess you also know that it can be made better - but it is still the 'best' as we currently have... 

Edited by littlesat, 6 December 2017 - 10:20.

[WanWizard]

When changes to provider files require changes to other files within the plugin, we increase the version number so that people cannot update the provider files using the GUI and cause it to crash.

 

Which is exactly what I mean.

 

Every change you make requires an update of the plugin, which in turn requires a build run of the image. That may work for images that have automatic nightly builds, but not for stable images that are not updated daily. The plugin has code in the data (python code in the provider xml) and dependencies between de xml and the code, so the user can't just update the xml.

 

If you have a plugin that has volatile data, you have to take this into account in the design of the plugin. You can't demand from end-users that they update daily, or flash the box every time a new version of the image comes out, and you can't demand from image builders that they keep on building every image daily until the end of time, just to keep up with your code updates.

 

This has nothing to do with snide swipes (at least not for me), it is purely a technical design discussion, intended to be collaborative, and definitely not offensive.

[Dimmie]

Unfortunately, autobouquetsmaker installed in 6.1 from feed, is still old version 2.8 which does not work. It needs to be version 2.9 to work.

[Abu Baniaz]

Unfortunately, autobouquetsmaker installed in 6.1 from feed, is still old version 2.8 which does not work. It needs to be version 2.9 to work.

Can you expand on what you mean by "it does not work"?

[WanWizard]

Unfortunately, autobouquetsmaker installed in 6.1 from feed, is still old version 2.8 which does not work. It needs to be version 2.9 to work.

 

I bumped the SRCREV to the latest one available, did I miss something?

[WanWizard]

I've checked. We have the version of 26/11 in 6.1-rc, and the version was bumped to 2.9 on 24/11.

 

I've bumped the SRCREV to 30abc381ca6d843383ed9ad402d3529f6d941390 for tonights build.

[Huevos]

 

When changes to provider files require changes to other files within the plugin, we increase the version number so that people cannot update the provider files using the GUI and cause it to crash.

 

Which is exactly what I mean.

 

Every change you make requires an update of the plugin, which in turn requires a build run of the image. That may work for images that have automatic nightly builds, but not for stable images that are not updated daily. The plugin has code in the data (python code in the provider xml) and dependencies between de xml and the code, so the user can't just update the xml.

 

If you have a plugin that has volatile data, you have to take this into account in the design of the plugin. You can't demand from end-users that they update daily, or flash the box every time a new version of the image comes out, and you can't demand from image builders that they keep on building every image daily until the end of time, just to keep up with your code updates.

 

This has nothing to do with snide swipes (at least not for me), it is purely a technical design discussion, intended to be collaborative, and definitely not offensive.

 

No. There is no "data" in the .py files. Every provider is different and things that are specific to a provider are contained in .xml files. The exact opposite of how Fastscan works. Fastscan holds the provider related data in the .py files.

 

When there are changes to a provider the .xml file for that provider gets updated. The xml files can be downloaded from the ABM GUI so there is no need for a plugin update.

 

But you can only download xml files for the current version.

 

OpenPLi in its wisdom has frozen the plugin on an old version. That means the .xml files can no longer be downloaded and then when there is a provider update the plugin gets a bad name for not working properly when the real problem is the code freeze imposed beyond the control of the plugin authors.

 

In other images where this code freeze does not exist issues are corrected and available to the plugin users within minutes of being reported.

Edited by Huevos, 10 December 2017 - 23:42.