Posts: 10,520
Joined: Sep 2003
Reputation:
10
Gamester17
Team-XBMC Forum Moderator
Posts: 10,520
Ideas wich could possible make a such scan less intrusive (less noticable for the user):
- it could be made optional.
- the process could be threaded to run in the background in its own seperate thread (on idle).
- it could be made to run only a second loop scan on existing library items like plooger suggests.
- it could feature all of the above.
Also note that a such scan for high-resolution video files would not be implemnted in XBMC for Xbox but only the other XBMC platforms (XBMC for Linux/Mac/Windows) where the hardware and underlying operating-system have more resources to offer XBMC.
Posts: 656
Joined: Jul 2004
Reputation:
2
@Gamester17: I think your solution was suggested previously in this thread. Personally I would prefer that information about resolution audio could be stored read from an .nfo associated with each file.
Posts: 656
Joined: Jul 2004
Reputation:
2
CapnBry -- while getting the information from the file itself is possible (although the thumbnail generator doesn't work on the xbox), I think it would be a huge overhead and scanning a music library would take forever. Basing it on the filename or an .nfo would mean that people that aren't interested in this feature wouldn't be affected.
Posts: 889
Joined: Jan 2008
Reputation:
11
Well it's been a while but I just wanted to pop in and say that I still want this feature more than any other, I hope some day a decision can be made and a dev will put it in :0) Thanks guys!
Posts: 854
Joined: May 2008
Reputation:
6
Just adding my vote, hopefully we'll see it in the near future.
Posts: 418
Joined: Oct 2004
Reputation:
0
I've spent some free time over the last week screwing around with this concept. Here's what I've got so far.
Here's what I probe:
Video: stream number, language, codec, format, width, height, display aspect, frame rate
Audio: stream number, language, codec, sample rate, channels
Video's "format" probably isn't useful, it is just the internal format of the video data, e.g. yuv420p. Other than that, this information is remarkably similar to the information already held in memory in the CDVDStreamInfo classes for CDVDPlayer material. What I was thinking for this first stab is to add something like this to IPlayer:
int GetFileStreamCount();
bool GetFileStreamInfo(int iStream, CDVDStreamInfo& pStreamInfo);
I don't know if there's any advantage to creating a new CStreamInfo class that doesn't come from the dvdplayer core. Then way up in application before we do an IPlayer::CloseFile() just see if there is stream info and if there is, copy it to the CFileInfo for the currently playing item. Finally have that object commit the information to the database.
The first question would be, should the StreamInfo be split into multiple tables? At first I thought this would be a good idea but I'm wondering if it would just be easier to pull all from one.
CFileInfo will also need to load this information from the database, just like it does for CVideoInfoTag. Now here comes the big question, how is it exposed to the skins? The issue is that there can be multiple audio and video streams which means the information should probably be flattened for use in list items. How the heck would that work? I mean should there be IsVideoSD IsVideo720 IsVideo1080 to determine if it is HD? The next problem is the audio track info. Being able to display a "Dolby Digital 5.1" logo or something would be nice but that would mean having a list item tag for each type of audio which could get out of hand.
So long story short, that's how it could work as a first attempt. The next step after that would probably be adding it when a thumb is extracted and then on video library scan (correct me if I'm wrong but this doesn't open the file at all currently). What else am I missing here?