1.32 X64 does not detect HD Homerun channels, 1.31 32-bit does (5 Viewers)

[Anthony Vaughan]

Well, it's not a problem to add extension exclude list to the MediaInfo service.
Anyway, if the MediaInfo is not available, then the video refresh rate(FPS) for the adapater cannot be determined.
There is alternate way how to get the fps(from videopin). It seems to be working (at least for my tested wtv file) and can be used as alternate option.

Hi Pablik

Well done on getting the conversion of MP1 to 64-bit.

I was wondering whether it would be better to populate the MediaInfoDtabase in GUIVideoFiles > LoadDirectories() where, if there is no media info record for each video in the directory, you add eah video to itemlist2 which is then processed in GetMediaInfoThread() to add each video to the MediaInfo database. This way the load of populating MediaInfo is done in the background and when you call Play() in g-player you will only have to get data from the media info database which uses less resource than writing data to the database. I've done this in my version of MP1 and there seems to be no performance hit.

Also, when a file is deleted,it might be an idea to delete the associated media info record if one exists.

Hope that helps.

 

[Pablik]

This way the load of populating MediaInfo is done in the background and when you call Play() in g-player you will only have to get data from the media info database which uses less resource than writing data to the database.

Hi,
to be honest, I'm not entirely sure what you mean by that. The async background scanning process is used if one of these conditions is satisfied:

• GUI option "Add media info to the video database for use in share view" is checked
• folder sort mode is set to Name + Duration

The MP 1.33 introduces new MediaInfo caching service. This service stores entire MediaInfoWrapper data to the database once the file scan is done. This caching speeds-up start of the playback of already played video.
The VideoDatabase uses this service to obtain the MediaInfoWrapper of the file.

 

[Anthony Vaughan]

to be honest, I'm not entirely sure what you mean by that. The async background scanning process is used if one of these conditions is satisfied:

Up until now the video database is only populated with media info data when you scan the video

Hi,
to be honest, I'm not entirely sure what you mean by that. The async background scanning process is used if one of these conditions is satisfied:

• GUI option "Add media info to the video database for use in share view" is checked
• folder sort mode is set to Name + Duration

The MP 1.33 introduces new MediaInfo caching service. This service stores entire MediaInfoWrapper data to the database once the file scan is done. This caching speeds-up start of the playback of already played video.
The VideoDatabase uses this service to obtain the MediaInfoWrapper of the file.

As I understand it, the GetMediaInfoThread() method/thread is used to ensure that all videos viewed in the directory structure are stored in the video database and that the duration of each video is obtained. The screen layout is also refreshed. At the same time RefreshMediaInfo() is called to get media info, if it is available. I believe that this happens irrespective of how 'share view' is set.

I was only thinking that it might be a good idea to populate the media info database in the same place as it performs this task for the video database.

The current code in 1.33 works so it is not essential to change it. Also, placing the check in LoadDirectory() is by no means straight forward because LoadDirectory has three routes and adding a video to itemlist2 would need to be placed in all three routes.

I only mentioned it because I thought it would be more obvious to populate the media info database in the same place as MP1 populates the media info for the video database.

Anyway, thanks for all the work you have done on getting MP1 to 64-bit.

 

[Anthony Vaughan]

The MP 1.33 introduces new MediaInfo caching service. This service stores entire MediaInfoWrapper data to the database once the file scan is done. This caching speeds-up start of the playback of already played video.

The main advantage of what I am suggesting is that, by populating the media info database in the background while loading directories before watching any videos, you gain the benefit of caching even for the first time you watch any video.

 

[Pablik]

The main advantage of what I am suggesting is that, by populating the media info database in the background while loading directories before watching any videos, you gain the benefit of caching even for the first time you watch any video.

I understand. But to be honest, I'd like to avoid scannig the files in advance. The background process doesn't stop until all files in the directory are done with the scanning. If you start the playback while the process is still running, than it can create huge load to the disk/nas/drive and can lead to choppy playback. From my experience, to scan a BluRay disc stored on NAS it sometimes takes more then 2 mins.
The option would be to terminate the background process if the playback starts.
Other option is to let handle the async requests by the MediaInfoService and remove that async background process entirely. I'll think about it.
Anyway, thanks for the posts and the thoughts, because it reveals that there is bug in MediaInfoService: if there are 2 same file request from 2 different threads, it can lead to create doubled record in the database. I gonna have to fix it in the next MP release.

 

[Anthony Vaughan]

I understand. But to be honest, I'd like to avoid scannig the files in advance. The background process doesn't stop until all files in the directory are done with the scanning. If you start the playback while the process is still running, than it can create huge load to the disk/nas/drive and can lead to choppy playback. From my experience, to scan a BluRay disc stored on NAS it sometimes takes more then 2 mins.
The option would be to terminate the background process if the playback starts.
Other option is to let handle the async requests by the MediaInfoService and remove that async background process entirely. I'll think about it.
Anyway, thanks for the posts and the thoughts, because it reveals that there is bug in MediaInfoService: if there are 2 same file request from 2 different threads, it can lead to create doubled record in the database. I gonna have to fix it in the next MP release.

Thanks for that. Glad it led to finding a bug.

 

[Anthony Vaughan]

Thinking about the bug you mentioned, I have split the Get() function into two functions, Get() and Set(), conditioned by a new HasFile() function that checks whether a record already exists for a given file.

Maybe that approach would help solve the possibility of writing two records for the same file?

 

[Pablik]

Thinking about the bug you mentioned, I have split the Get() function into two functions, Get() and Set(), conditioned by a new HasFile() function that checks whether a record already exists for a given file.

Maybe that approach would help solve the possibility of writing two records for the same file?

Thanks, I already have prepared the fix.

 

[Anthony Vaughan]

I'm getting an error on my development machine where, only when I first call MP1, but not in subsequent calls during the same session, where the volume control for the machine appears at the top left hand corner of the screen and I see this in the log:

[ERROR] - HideVolumeOSD: OSD window not found!

Is anyone else seeing this?

This error is generated in FindOSDWindow() in HideVolumeOSDLib.cs which was changed in 1.33.

The sound card is a RealTek and I'm using digital output.

I'm going to change the code back in that file and I'll reboot the machine and let you know what happens.

 

[Anthony Vaughan]

That didn't change anything. I guess the problem lies deeper in the code. I'll revert Mixer.cs next.