View Full Version : Editing Database entries
Hi, this is an split-off of my original request (http://xbmc.org/forum/showthread.php?t=43152).
I'd like to do some simple editing of an entry and don't want to fire up an external application like sqlitespy or sthg else for that. So a simple in-place form would be enough for that. Of course, this information should afterwards not be updated by the scraper again. But only this info. If possible.
http://xbmc.org/trac/ticket/5407
Oops, I'm sorry, but probably it helps in forcing this issue to higher priority.
Is there a voting or some kind of that?
No, but there probably should be.
I think there is a trac plugin available for that ;)
Gamester17
2009-01-06, 22:38
Oops, I'm sorry, but probably it helps in forcing this issue to higher priority.You have to understand and respect that XBMC is 'only' a hobby project, please read this explanation here:
http://xbmc.org/wiki/?title=What_is_XBMC_%26_What_Can_it_Do%3F#When_wil l_this_and_that_feature_or_function_be_supported_b y_XBMC.3F
:rolleyes:
Shame on me for asking that impolite.
I know about and have greatest respect for the work all coders all over the world do. And I surely didn't want to step on someones shoes. :no:
jmarshall
2009-01-07, 02:36
Ideas for it are welcome, and should ideally be added to the trac ticket. The main problem is making the implementation of it skin agnostic. As it currently stands, the video info window allows content to be placed practically everywhere. If we allow it to be editable, this restricts things somewhat (the information must then be able to be navigated to and so on) for the skinner.
I'm particularly interested in what the skinners think. The library views now offer a reasonable amount of information by themselves, so that the video information window can perhaps be moved towards allowing editting to take place.
The final problem with allowing editable information is it then should not be overwritten by future scraping of information. One idea would be to store the edited information with a certain prefix that dictates that it's the user's data, rather than scraped data.
Cheers,
Jonathan
Special Edit dialog? (replacing Edit name in context menu), where a skinner could choose what db fields he includes.
Agree on the owerwrite part, that is perhaps the biggest code challenge?
It could be an extension of the mixed xml/url nfo stuff, so it only writes changed fields to an nfo, xxx-userdefined.nfo perhaps?
jmarshall
2009-01-07, 23:10
I was thinking a more simple way would just be a prefix in the db (eg ***<field goes here> indicates it's a user-defined one).
IMO the video info dialog is kinda useless for the most part other than for editting, so I'd prefer to reuse if possible. We could perhaps start with a new one and then replace later though.
Cheers,
Jonathan
That would definitely call for sql refresh in place :)
My suggestion would survive a db vipe, but I guess there is no mandate for that.
I use the media info window extensively.. IMHO the standard views in both PMIII and PM3.HD are rather spartan (sometimes you can only wonder how much the devs actually use their product :p )
The main problem is making the implementation of it skin agnostic. As it currently stands, the video info window allows content to be placed practically everywhere. If we allow it to be editable, this restricts things somewhat (the information must then be able to be navigated to and so on) for the skinner.
What about an additional button which either switches to the 'edit'-mode or forwards to an additional edit-window? The latter could be implemented as a kind of standard-window, independent form the used skin. The look-and-feel would be broken in that part but on the other hand the skinners would not be responsible for implementing the edit-stuff correctly. They just need an additional buttton. Maybe we could also go with a special key, so no ones gonna come to the edit window by inadvertently choosing a menu-button.
Experienced skinners could then implement the stuff by themselves and keep their look and feel.
The final problem with allowing editable information is it then should not be overwritten by future scraping of information. One idea would be to store the edited information with a certain prefix that dictates that it's the user's data, rather than scraped data.
That's absolutely correct! This problem exists already as items cannot be updated by using another scraper for example. IMHO this is a core problem of xbmc.
It could be an extension of the mixed xml/url nfo stuff, so it only writes changed fields to an nfo, xxx-userdefined.nfo perhaps?
Sounds very interesting! Is there already the ability of using database entries and .nfo? Didn't hear about it yet.
I was thinking a more simple way would just be a prefix in the db (eg ***<field goes here> indicates it's a user-defined one).
Right, this would be a very simple, but effective way of separating database entries. In the end, there could be more than one prefix. For example one indicating user additions, one indicating updatable stuff, one indicating the used scraper and so on. Of course, the complexity of the db-scheme would increase by this.
IMO the video info dialog is kinda useless for the most part other than for editting, so I'd prefer to reuse if possible. We could perhaps start with a new one and then replace later though.
What exactly do you mean? Are we talking about the info that pops up when prssing 'i' on an item? The one which shows cover, actors, director etc.? I don't find it useless, as this window gives me most information about an item.
No, but there probably should be.
I think there is a trac plugin available for that ;)
That is definitely a great idea! Would be awesome... :nod:
Someone has to sell it to the team:
http://trac-hacks.org/wiki/VotePlugin
BaerMan:
http://xbmc.org/wiki/?title=Nfo
BaerMan:
http://xbmc.org/wiki/?title=Nfo
I already know this page, but as I understood, the .nfo is read once and the resulting info (either from xml-nfo or from pointed url) is then written to the database. Afterwards just the entry in the db is used. Did I misunderstand this?
I read your posting as if there could be a .nfo additionally to the database which is being evaluated everytime the info for an item is asked for. This could be a proper way for updating infos on-the-fly.
No, if I in any way implied that, it's wrong.
Allright, so I misunderstood your post.
Nevertheless, I vote for a "double-source" like this. :nod:
What I proposed was not that the nfo would be read continously, only that it would contain the modified entries and thus the data would survive a db wipe.
it's actually nice to see you guys are thinking about how this could be done.. sounds promising to me :)