Suggestion: Pre UI loading...
Opened this issue · 5 comments
You might want to consider a different way/strategy of loading m3u files, since some m3u's are getting pretty tremendous.
3 strategies I can think of off the top of my head:
-
Let user know there is limitation to file size and that files over a certain file size will be split into multiple .m3u files. Make it where user could export manipulations to re-merged master .m3u file. Another idea split the .m3u silently and use a pages layout for your table instead of a scrolling layout. When switch pages or maybe multiple pages it loads from another file in the background(instead of loading the complete file into memory).
-
Change strategy of how file is being loaded. Load only so many lines of the file at a time. Keep a pointer to where you are in the file and work your way up and down as people transverse the .m3u list. You may have to put some kind of spinner for loading of new content. One of the main downsides of this is figuring out how to make a search function work well. You could parse the file in the background without completely loading the data into memory or at least avoiding it visually in the GUI.
-
Pre-Main GUI initialization convert to a sqlite db. Then just run queries against the database. Also UI elements can utilize the db over loading the whole m3u files at once. Some UI elements pull data as needed from db to display it instead of loading everything in memory and forcing it on the UI.
3rd option would probably be the best way to solve the issues. I might fork and mess around with it a bit. My eyes aren't so good anymore and I get severe headaches when I strain them to code for extended periods of time.
Please take my suggestions as only constructive suggestions. Thanks for your time and effort you have put into the project!
Please enlight me, why has somebody m3u lists with thousands of iptv links? You cannot watch them, or? What are you doing with it? The code was a spin off from my Kodi m3u playlist editor and is getting hard to change for bigger things. Such changes would be an idea for a new codebase with WPF UI. Will think about it. PS had eye problems with working on screens too and found out that I had zinc and vitamine A level too low, both leading to bad eyes. On Tuesday, January 30, 2024 at 07:11:04 PM GMT+1, Christopher Whitehead @.> wrote: You might want to consider a different way/strategy of loading m3u files, since some m3u's are getting pretty tremendous. 3 strategies I can think of off the top of my head: - Let user know there is limitation to file size and that files over a certain file size will be split into multiple .m3u files. Make it where user could export manipulations to re-merged master .m3u file. Another idea split the .m3u silently and use a pages layout for your table instead of a scrolling layout. When switch pages or maybe multiple pages it loads from another file in the background(instead of loading the complete file into memory). - Change strategy of how file is being loaded. Load only so many lines of the file at a time. Keep a pointer to where you are in the file and work your way up and down as people transverse the .m3u list. You may have to put some kind of spinner for loading of new content. One of the main downsides of this is figuring out how to make a search function work well. You could parse the file in the background without completely loading the data into memory or at least avoiding it visually in the GUI. - Pre-Main GUI initialization convert to a sqlite db. Then just run queries against the database. Also UI elements can utilize the db over loading the whole m3u files at once. Some UI elements pull data as needed from db to display it instead of loading everything in memory and forcing it on the UI. 3rd option would probably be the best way to solve the issues. I might fork and mess around with it a bit. My eyes aren't so good anymore and I get severe headaches when I strain them to code for extended periods of time. Please take my suggestions as only constructive suggestions. Thanks for your time and effort you have put into the project! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.>
The reason I personally used your tool is actually to trim those lists down to reasonable channel lists. Your wondering why someone would have lists that long is exactly the reason I'm using your tool, I didn't create the original .m3u/.m3u8 lists(probably like most people don't). I would never create a .m3u list with that many channels, but you got to deal with what ya got. Also you can add VOD type content, which I don't, into those lists. Just 1 popular TV series could be 100 or more entries.
After I tried out your tool I wrote a Python script that would just split the lists up, then I feed them into your tool and filtered out different channels(I have tried 5000 entries at a time, which worked fine in your tool). I haven't thoroughly used your tool, so I'm not sure of it's complete capabilities. If you want the Python script I can post it back. Would need to add a command line -help feature and add some error checking though.
Yea, when I said searching earlier I was referring to the highlighting. I usually read back over my posts because I'm bad about completing half thoughts then going on to something else. I figured you knew what I meant, but a real search filter/feature would be much much better. Currently if you do a search it highlights based off what you type.
One other tip about the search feature. You may want to wait until there is a minimum of 2 chars in the search box before searching. On larger lists it will sit there and stall out just from typing 1 letter at a time. I understand what you were going for with the search feature and I'm sure it works like you want on small sets of data. You were trying to implement a more responsive search, but that's one of the downfalls of it(I've run into that myself before). Another tip if you want to even take it further. Say you change it to a 2 char minimum before searching. After the person types 2+ letters, start a timer after they type the last letter for about 3 seconds before you start their search query. If they start typing again before that 3 seconds you cancel the search and then when they stop typing for 3 seconds it searches for that query. It could be 2 seconds, you have to figure out the number that seems natural to actually respond to the query. It keeps the search from being so jarring. I think you understand what I'm talking about.
These are just suggestions. I understand this is just something you did on the side and you may not have the heart for it anymore. Many a projects I started in the past died by the wayside. You work on it to get basically what you want to accomplish, then you get bored with it and don't care about making it into some professional product(and that is fine). You learned a lot of stuff a long the way of making the project and you are happy that it did whatever you wanted it to. People start giving suggestions and some of them you may actually think are good. Problem is, deep down you really don't care that much anymore because the initial need has been fulfilled. It's just not worth your time anymore.
These are not features I'm requesting of you. I appreciate that you were willing to share your tool instead of me having to go write one myself to do similar things. If "you" want to take the project further or maybe just learn some new tricks then the suggestions above are some things you may think about. That's all I'm saying here. I've already got my primary use out of it and I probably will use it again in the future. If there are some new things you do to it, heh great.
Thanks again for sharing and saving other people time...