36 replies to this topic

[Dream1975]

Quick question, why are the normal sources in the beginning of the list and the xz versions at the end? To reduce data consumption you want people to use the xz version (and only use the other ones only if they don't work). Wouldn't it be better than to put the xz versions in the beginning of the list (and maybe also put in the latter ones in the description that these are only for in case the xz version doesn't work)?

Edited by Dream1975, 22 August 2017 - 08:53.

[doglover]

Not every-one can use the xz sources yet.

 

This modification is planned for at the end of september.  By that time most people would have updated their receiver I hope.

Then I switch both around (gz at the back).

 

Planning is that at the end of the year, gz is switched off, and then I will remove them.

The dilemma I am faced with this is, do I remove the xz indication?  Because that will mean everyone will have to reselect their sources...

(I guess I did not think enough about this when I first started working on this)

 

Willy

Edited by doglover, 22 August 2017 - 09:07.

[Abu Baniaz]

Just the EPGImport.py file.
The other one is for the expandable source list (treeview) which has nothing to do with this.

Just to be safe, I will test that one also.

Willy

I was referring to new lines 67-69 of xmltvconverter.py which deals with enumerating files, not indent.

P.S
Is that pull request about deleting EPG.dat going to be merged?

[doglover]

Damn: missed that  (i am getting old and senile I think)

 

Willy

[doglover]

Exactly the same.

 

Willy

[Pr2]

Hi Willy,

 

I think that if by end of the year .gz will no longer be supported, it would be nice to already mention it in the "sourcecat" message. By adding something like:

 

(End-of-life 31/12/2017) Rytec General XMTL (.gz)

(End-of-life 31/12/2017) Rytec Deutschland/Osterreich/Switzerland XMLTV (.gz)

(End-of-life 31/12/2017) Rytec Belgie/Belgique/Nederland/France XMLTV (.gz)

 

Putting it in front will keep the alignment and will ne nicer to read. This is a warning that won't harm the existing selection and adding (.gz) at the end draw the attention on the compression format used and perhaps in the sourcecat for the (.xz) version add:  

(NEW format!) Rytec General XMTL (.xz)

(NEW format!) Rytec Deutschland/Osterreich/Switzerland XMLTV (.xz)

(NEW format!) Rytec Belgie/Belgique/Nederland/France XMLTV (.xz)

 

I think that this will make think clearer for people that use xmltvimport / EPGimport without reading satellite forums.

 

By the way, there is a bug in the "Rytec Ellada XMLTV (xz version)" . we saw a /description.

 

Regards,

 

Pr2

[doglover]

By the way, there is a bug in the "Rytec Ellada XMLTV (xz version)" . we saw a /description.

 

 

Removed it.

Did not hamper the functionality though.

 

Willy

[doglover]

@Pr2

 

I will put this warning in the sources file. 

 

Willy

 

PS: remember: The Spanish, Portugese, Greek, Hungarian, Csat Overseas, Czech/Slovak and Bulgarian sources do not work yet in xz version.

The problem is not the production of xz files.  But I grab these on a separate PC, and this has a very slow internet line for upload.  First I have to terminate the old large files before I can make room for the xz files.  This will be done end of sept.

 

Willy

Edited by doglover, 22 August 2017 - 10:10.

[WanWizard]

Willy,

 

I only checked and fixed the problem with channel files. Are you saying that the same problem exists when an XMLTV data file can't be downloaded?

[doglover]

No.  Then you misunderstood something along the way.  With XMLTV files there is no problem. 

 

Willy

[WanWizard]

Ok. So just to be sure I know where we are now: the problem with failed channel downloads is sorted with last nights fix then?

[doglover]

No.  See my post #16.

 

I forgot the test in the first place the corrections in XMLTVconvertor.  But did that also.  But the same result.

The remark I made in post #16 still stands. Let's put in pause in the efforts, something wil crop up.

 

Willy

[WanWizard]

I can't reproduce that with today's plugin. The import runs fine here (providing there is a channel file that can be downloaded).

 

As you also showed me a screenshot with an old treeview layout (I have send you a screenshot of mine here), you may perhaps have the wrong version. Mine btw is not a development version, it is updated this morning from the feed (OpenPLi 4).

[doglover]

I am sure, I have not the wrong version.  It is from the 6.0-rc updated this morning.  And the XMLTV importer updated from the development pages on the Github (by copying the relevant .py files by hand to the receiver)

All testing has been done this way.

 

Willy

 

PS: In 6.0-rc the XMLTVimporter is not the latest version.  Do not misunderstand me, this is just the observation, nothing else intended.

Edited by doglover, 22 August 2017 - 13:34.

[WanWizard]

The RC image doesn't start building until 12.00 your time, and usually builds for around 6 hours. So any change made yesterday will not be in the image until this evening,

 

I have this one running

Package: enigma2-plugin-extensions-xmltvimport
Version: 1.0+git124+a64fbeb-r0.0
Depends: python-lzma, python-pkgutil, libc6 (>= 2.20), python-compression, python-shell
Recommends: enigma2-plugin-extensions-xmltvimport-rytec
Status: install user installed
Section: base
Architecture: mips32el
Maintainer: MiLo, rytec @ pli-images.org
MD5Sum: 040058653d7ffb31981f7b95aa3acb38
Size: 94642
Filename: enigma2-plugin-extensions-xmltvimport_1.0+git124+a64fbeb-r0.0_mips32el.ipk
Source: git:///openpli/OpenPLi/enigma2-plugin-extensions-xmltvimport.git
Description: enigma2-plugin-extensions-xmltvimport version
 1.0+gitAUTOINC+a64fbeb59f-r0  Imports xmltv files into the EPG cache of
 enigma2
Installed-Time: 1503399559

which is this version: https://github.com/O...abf2df5bd041005

 

and which works fine here. With working and non-working channel URL's. Online and Offline.

[WanWizard]

What I just thought of: if you got only the source of EPGImport.py from github, you don't have the fix.

 

The problem wasn't in that file, it was in the importer itself (xmltvimporter.py), it caused an Exception when trying to import a data file with no channel definitions loaded, which is why it seemed to hang (it didn't, it just aborted without errors).

 

edit: this fix to be exact: https://github.com/O...9c2d93e1bba8b95

Edited by WanWizard, 22 August 2017 - 15:15.

[doglover]

I got that one also.  But I admit only in the last try.

 

Willy