Closed kkdexz closed 2 years ago
ale5000-git
commented
2 years ago Having too many elements in a single menu is cumbersome. I think it would be nicer to separate in two submenus:
This will also simplify the code and reduce memory since Youtube-DL elements need to store 2 urls (if I'm not wrong) instead local files just a local path.
clsid2
commented
2 years ago Is 100 enough?
Because your method of playing things seems a bit weird to me. So I am inclined to just say no to any further increase.
kkdexz
commented
2 years ago Is 100 enough?
Because your method of playing things seems a bit weird to me. So I am inclined to just say no to any further increase.
I mostly use it when I have a saved playlist of a series/podcasts/audiobooks, etc, or even movies, sometimes comprised of several seasons, or a set of different but related series, that are all saved in separate folders, but are in the specific order in which I want to listen/watch them, e.g. chronological order, release date, downloaded date, grouped by genre/theme, etc, not necessarily alphabetical/numerical order. This way I can just pop in the playlist and start watching where I left off, i.e. "set and forget". This lets me know what I watched/haven't and also serves as a sort of "to-watch" list, as its name implies, w/o going purely off memory, or bringing up an external app/physical pen+paper. It also lets me continuously add further items to the bottom, or w/e I want them in the playlist, as needed. Some of these playlists can get quite long.
But the way it is currently, if I decide to take a break and start watching something else, go on a YT binge, listen to random music, etc, after 50 items, I no longer know where I left off and can't just click once to "resume" my playlist.
I currently have it set to the max allowed at 1000 (I'm also a very, very tab-heavy browser user, so the 2 are prob related, like an OCD kinda thing?). Does this really bog down the system under the new file history implementation? Given that it's only the UI that's affected. Or is it just "messy"? It's in its own scroll-down submenu. As it is now, if you have it set at 50+, you still have to scroll down, since all 50 don't fit on my 1080p display. It just...scrolls down less.
I realize I'm a pretty niche/fringe use case and it isn't reasonable to expect the app to cater to only my needs if it negatively affects other users. But this is where I think an option/setting would be appropriate, similar to how RecentFilesNumber used to act. If an user doesn't want to see it, they don't have to see it, particularly considering the default setting + being buried in Advanced. IMO, this function is more important than remembering playback position past 50 (yes I know the 2 are linked). But again, it's your project, which I respect.
But yes, 100 would still be better than 50. It's more of a convenience than an essentiality and I guess I've just gotten used to it. The change was just a bit abrupt is all. Now that I think about it, I could just look under the dropdown menu and then manually scroll down my playlist to find it. A bit more of a hassle/time-consuming but not that big of a deal. Although would still be nice if the dropdown menu also saved titles, esp/if only for streaming URLs, as I also do stream quite a bit.
TL;DR : 100 would be appreciated. Thank you.
kkdexz
commented
2 years ago Thank you! Very much appreciated.
I wanted to continue experiencing the new features/bug fixes, but was seriously debating whether or not to ever update from 1.9.19.21 and just stay on it forever lol. But looks like that's no longer the case now.
You have no idea how important/valuable your work & continuing development on this is, just keeping it alive. This was, is, & always will be the best Windows media player of all time due to you. Irreplaceable imo. Thanks again!
I was wondering if you could possibly revert it so that it shows more than 50 items, especially if settings -> advanced -> RecentFilesNumber has been modified to do so, or at least provide an option for the user to choose? The last (nightly/dev) version I've used that kept this behavior was 1.9.19.21 (but probably 1.9.19.26 to be more specific), as it seems the change was made in 1.9.19.27 (commit bfb7769). The most recent version that I have tried is 1.9.19.42.
Given that #715 is not yet a thing (which I only discovered recently), I relied heavily on the recent file history to show me where I last left off, especially if an extended amount of time has passed (or > 50 other files have been played), and if the file is included in a loaded playlist.
From reading #1384 and the comments under commit 96a8780 (1.9.19.26), it seems that the recent file history + playback position > 50 items is still saved under the new config, just not in the file menu UI. I confirmed that they indeed are listed in the dropdown menu under file -> open file/url, but this is not really an acceptable substitute for my use case imo.
For 1), it doesn't save titles, only locations/URLs (ok, not completely necessary, but still a nice bonus. Although still pretty important for e.g. youtube links). And 2) I am a heavy playlist user. Under the old behavior, if I had a playlist open, and I clicked on an item in the recent file list, it would automatically play that file if it was included in said playlist while leaving the playlist untouched, i.e. just scrolled down to its place in the playlist. Whereas doing file -> open dropdown menu, the only 2 options available would be to either add the chosen file to said playlist, where it would be added to the very bottom, possibly becoming a duplicate entry; or to clear the currently loaded playlist entirely to play said file, where it would be the first item listed in a new "playlist". Not as convenient.
I realize that another possible workaround would be to add the file to favorites, where it still retains this behavior of going directly to the file in the playlist when clicked, but this is also a bit inconvenient and cumbersome. I would have to constantly remember to add the file that I would want to be "saved" for one, but not just any file, only those that I would expect not to watch the next entry for a period of time or specifically > 50 files in between. I would essentially have to forecast and see into the future whether it was needed or not. Either that or save after every single item in the playlist watched, just to be safe, and remember to trim my favs list. Secondly, I would have to discern whether any entry in my favs list was just a placeholder for my history, or was added there bc it really was one of my favs. Plus I would always have to scroll down to the bottom since that's where they are added (would be nice if we were able to change the sorting, which would be a great feature request if you were accepting any lol)
From what I can see, I'm not even sure why this change was made, as it just seems like a personal or aesthetic preference more than anything, rather than any bug fix or feature addition, i.e. just a feature removal (?), given that it was working fine pre-1.9.19.27, and it only affects the UI. But I'm not a developer, so you'll have to excuse my ignorance. I'm assuming it likely had to do with the post-1.9.19.27 recent file history code changes, or perhaps performance tuning?
If it's a quick fix w/out causing any additional issues, then would appreciate if you could revert it, or at least provide an option in the settings somewhere. If it's a lot more complicated than that, I understand. Thanks again for your continuing development.