EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Issues with Windows Media Center

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#21237
Posted: 08/29/2012 12:04:33
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

A number of my users have reported an issue that can be summarized as follow:

- Live TV buffer works fine recording to the FlexRAID drive.
- Scheduled TV shows will record fine to the FlexRAID drive.
- Recording a channel and then tuning into it results in one of the errors above.
- Watching a channel and then recording results in one of the errors above.

Read more in this post: http://forum.flexraid.com/index.php/topic,969.msg9030.html#msg9030

It reads almost as if there is some sort of sharing violation.

I had the users capture the user mode logs in TRACE mode to see if there was any issue in the callbacks on the FlexRAID side. However, the logs are clean (no error), which leads me to believe the issue is at the driver level.
The logs are here: https://docs.google.com/file/d/0B74t-gXEouiHRDZhMTd2UjRxdUU/edit?pli=1

What additional information would you guys need to help troubleshoot this issue?

Thanks.
#21238
Posted: 08/29/2012 12:36:25
by Eugene Mayevski (EldoS Corp.)

If you think this is sharing violation, you should review how you handle opening and closing of files. By default Callback File System doesn't call OnOpenFile if the file is already opened (and doesn't call OnCloseFile for the file opened more than once). If don't count for this, then problems are likely.

If you need to track each open and close operation, set CallAllOpenCloseCallbacks property to true. Yet you need to remember and take into account that the context which you set in OnOpenFile is the same for all parallel open operations.

Here's what happens:

1) Application A opens file X. You handle the OnOpenFile event and set UserContext T.
2) Application B opens file X while it's already opened in App A. If CallAllOpenCloseCallbacks is false, then you get no notification. If CallAllOpenCloseCallbacks is true, you can handle OnOpenFile event BUT context T is already set and setting a new one will replace the previous context T (Vladimir will correct me if I am wrong here).
3) Application A closes file X. If CallAllOpenCloseCallbacks is false, then you get no notification. If CallAllOpenCloseCallbacks is true, you can handle OnCloseFile event, but context T remains valid.
4) Application B closes file X. You get OnCloseFile and context T can be released (i.e. if it pointed to some object, then you can free the object and its memory).

Before we go further with investigating WMP problems, please rethink your handling of file open/close operations and check that you handle them right.


Sincerely yours
Eugene Mayevski
#21239
Posted: 08/29/2012 13:37:47
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Hi Eugene, thanks for the reply.

So, here is the thing. There is only one application: WMC.

When I say "sharing violation", I don't mean it in the typical case of the Windows API. I meant to say that WMC is appearing to have an issue doing two things on the same file (record and watch or watch and record).
In other words:
- If the user is recording a show, there is an issue if the user tries to watch the show after it has already started recording.
- If the user is watching a show and pushes record, there is an issue do that also.

I also don't think the issue is at the Callback level as typically a sharing violation would manifest as an error, which would be logged. Essentially, there is no error at the Callback level, which leads me to conclude whatever is going on is happening at the driver level never reaching the callbacks.

Thanks.
#21240
Posted: 08/29/2012 13:49:24
by Eugene Mayevski (EldoS Corp.)

Quote
Brahim Bakayoko wrote:
So, here is the thing. There is only one application: WMC.

When I say "sharing violation", I don't mean it in the typical case of the Windows API. I meant to say that WMC is appearing to have an issue doing two things on the same file (record and watch or watch and record).


Being one application does not prevent it from opening the file twice. Moreover, knowing the module architecture of DirectX and WMP (which AFAIK uses DirectX) I can ensure you that different modules that open the file can know nothing about each other.

Quote
Brahim Bakayoko wrote:
I also don't think the issue is at the Callback level as typically a sharing violation would manifest as an error, which would be logged. Essentially, there is no error at the Callback level, which leads me to conclude whatever is going on is happening at the driver level never reaching the callbacks.


Let's get back to previous topic - do you set CallAllOpenCloseCallbacks to true in your code?


Sincerely yours
Eugene Mayevski
#21241
Posted: 08/29/2012 14:10:55
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Eugene,

No, I have not set CallAllOpenCloseCallbacks to true in my code.
#21246
Posted: 08/30/2012 01:11:51
by Eugene Mayevski (EldoS Corp.)

Then most likely you will need to do this and rethink your OnOpenFile and OnCloseFile event handling. We will add the task to check WMP behavior with CallAllOpenCloseCallbacks set to false, however, it will not be fast as we have things related to Windows 8 and CBFS 4 to be done first.


Sincerely yours
Eugene Mayevski
#21247
Posted: 08/30/2012 01:14:07
by Eugene Mayevski (EldoS Corp.)

BTW did you manage to reproduce the behavior your users described or all we have is their reports?


Sincerely yours
Eugene Mayevski
#21265
Posted: 08/30/2012 07:42:13
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Eugene,

Unfortunately, I don't have a working WMC test bed to replicate the issue at this time (need to build a new one). So yeah, I am going solely by the users' reports and logs.

Setting CallAllOpenCloseCallbacks to true and opening up a whole can of worms is just not a strategy I am up to at this time either. I am eagerly awaiting CBFS 4 and prefer not to do any major overhaul till then.

Now tell me, when CallAllOpenCloseCallbacks is false and AppB calls to open a handle that has already been opened by AppA, what is the driver returning to AppB? An error code or the handle already opened by AppA?

Thanks.
#21266
Posted: 08/30/2012 07:45:43
by Eugene Mayevski (EldoS Corp.)

Quote
Brahim Bakayoko wrote:
Now tell me, when CallAllOpenCloseCallbacks is false and AppB calls to open a handle that has already been opened by AppA, what is the driver returning to AppB? An error code or the handle already opened by AppA?


This depends on flags and attributes requested. If flags are conflicting, error would be returned. I.e. if your first open was for writing only, and second is for exclusive reading (for example), that's a conflict and error will be returned. Otherwise the file will be opened the second time (another handle would be returned to other application but the same user context will be passed to your file reading/writing code for operations coming from both applications).

So I suspect that your only option is to CallAllOpenCloseCallbacks to true to resolve this problem as there's no error on driver side - it does what is requested.


Sincerely yours
Eugene Mayevski
#21278
Posted: 08/30/2012 10:17:27
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Quote

...
So I suspect that your only option is to CallAllOpenCloseCallbacks to true to resolve this problem as there's no error on driver side - it does what is requested.

Well, I am struggling to understand what I would do differently here that the driver isn't already doing. I mean, I would be throwing the same error as the driver would or opening up a new handle as requested.

It is not my intentions to want to override and violate any condition that the filesystem would otherwise not allow.

What are your thoughts?

Thanks.
Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages

Reply

Statistics

Topic viewed 5094 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!