(2013-11-12, 09:25)Ned Scott Wrote: [ -> ]Refresh?
Change content?
Scan for new content? (very "maybe" on that one. not sure)
The last two are only available in files view and probably are the most used context menu items for source items. That's why I don't think that a "Manage..." sub-menu makes sense there. I can look into if it's possible to add "Refresh" (from the video info dialog).
popcornmix: What was the reason you had to mark a whole heap of episodes as watched? I'm genuinely intrigued as to the usage pattern, as I never use mark as watched (or unwatched) at all as it's automatically done once I've watched something.
Given Mark as Watched appears to be the most used Manage... option, perhaps it should be first? This would get rid of those that complain of it being in the main context as well as the manage menu.
I propose to move all the "go to X" entries in the PVR EPG context menu to a "go to..." submenu (like the "manage...") to clean that thing a bit up. Those are probably rarely used. Talked about it with xhaggi already and he's also fine with it. What's the RMs view on this?
(2013-12-29, 02:59)jmarshall Wrote: [ -> ]popcornmix: What was the reason you had to mark a whole heap of episodes as watched? I'm genuinely intrigued as to the usage pattern, as I never use mark as watched (or unwatched) at all as it's automatically done once I've watched something.
I think there have been 3 different occasions I've needed to "mark as watched" large groups:
Initially when I moved from using a different media player to xbmc, and was partway through a number of series.
After rescanning my library when I had a few series that weren't detecting new episodes. I backed up and restored the watched status with Milhouse's texture cache utility, but about 10% of series didn't restore the watched state correctly (possibly due to minor changes in series name).
When I've replaced a series with a higher quality version (e.g. sickbeard's archive version). The watched settings get lost here.
Marked as watched for large groups of videos will be useful until we have a means of maintaining a persistent library. Might be something to think about as development on multi-client really gets rolling.
popcornmix: Thanks, that's useful.
A user in another thread (
http://forum.xbmc.org/showthread.php?tid=194294 ) was asking if "Scan for new content" could still work if a playlist is selected. I guess this is something that used to work, where the user has a playlist of TV shows, and they could scan for new library content on just that specific set of shows. The "Scan for new content" context item doesn't show up, but is that because it can't work anymore or because it's just not exposed in those situations?
Normally, I would say that this isn't much of an issue because "Scan for new content" is really just meant for folders (and TV shows, which are basically folders), but the use-case is actually a really great idea and I could see it being a nice way to do partial library updates, as updates can take a long time on some devices or based on the size of the library/number of shows.
If it's something that would be a lot of work, no worries, but I thought I would ask in case it's just something that might be possible to expose.
TBH I didn't know that's even possible and I don't see how it would work. Maybe jmarshall can enlighten us. It should still work on a per tv show bases though.
I don't think it was ever intentional, and there was certainly no code to only grab the paths of items in a smartplaylist or whatever.
I doubt it's worth the code overhead - there's too many pitfalls where it wouldn't actually do as described (the paths contained in the smartplaylist may contain a bunch of other things not in the smartplaylist).
Yeah that's what I thought. I'm not very familiar with the scanning code but I didn't remember it working that way. It only works on items that have a path which can be looked up in our database to find the appropriate source and scraper which is not the case for a playlist.
Fair enough, thanks for explaining it to me :)
I've started to see reports of people complaining Now Playing has been removed from the Context Menu, see
http://forum.xbmc.org/showthread.php?tid=195026 and I've seen other posts on the subject to.
I fully understand the reason behind the move and the renaming to Current Playlist, as it's not a contextual item then the view was it has no place there, but I can also understand the user argument that you queue items from the Context Menu and it's easier and more intuitive to enter the playlist of queued items from the Context Menu after you've queued them up.
(2014-05-15, 16:17)jjd-uk Wrote: [ -> ]I've started to see reports of people complaining Now Playing has been removed from the Context Menu, see http://forum.xbmc.org/showthread.php?tid=195026 and I've seen other posts on the subject to.
I fully understand the reason behind the move and the renaming to Current Playlist, as it's not a contextual item then the view was it has no place there, but I can also understand the user argument that you queue items from the Context Menu and it's easier and more intuitive to enter the playlist of queued items from the Context Menu after you've queued them up.
I can see the point but the problem is if we follow this line of thought we can put everything back into the context menu. You can start playback from the context menu so why should the "Full screen" button or the player controls not be in the context menu button as well?
Indeed. I have no doubt that we could expose the Current playlist button better (outside of the sidebar menu for example), but I don't think the context menu is the right place.