Here is the problem: 1. Use a MCE (Microsoft Media Center) 2005 PC to record live TV and play at the same time, default it records into local hard drive. To record into a network share, you need install TweakMCE from Microsoft: http://www.microsoft.com/downloads/details.aspx?FamilyID=3400190a-511a-4a3a-9b89-524511a76f58&DisplayLang=en And use TweakMCE, you can setup "Record" and "Watch" folder like "\\192.168.1.100\media", and restart Media Center application to refresh it, not restart MCE PC, because it will back to local disk after reboot. 2. Use a Linux 2.4.20 PC and Samba 3.0.21a, glibc 2.3.2 to setup a network share for MCE to store record files. 3. Then use MCE live TV, select Record to start recording. 4. Then you will see the MCE play is freezed. But the MCE 2005 can record and play at the same time in local disk and Samba 3.0.11 seems work OK too. So this seems a problem in Samba 3.0.21a.
Jason, please retest 3.0.21b. We fixed a few significant file sharing bugs and I'm curious whether or not that will help you.
I test the 3.0.21b release with MCE 2005 today. It still freeze the play while recording to Samba Share.
Ok, can you get us a debug level 10 log from smbd whilst this is going on, as well as an ethereal trace between client and server ? That would help a lot. Thanks, Jeremy.
Here is smbstats for 3.0.21b, and I will send log.smbd and ethereal soon. Samba version 3.0.21b PID Username Group Machine ------------------------------------------------------------------- Service pid machine Connected at ------------------------------------------------------- media 10718 192.168.7.162 Tue Jan 31 14:19:39 2006 Locked files: Pid DenyMode Access R/W Oplock SharePath Name ---------------------------------------------------------------------------------------- 10718 DENY_WRITE 0x3019f RDWR LEVEL_II /c/media MSDVRMM_927466607_14848_131074.tmp Tue Jan 31 14:19:41 2006 10718 DENY_ALL 0x0 RDONLY NONE /c/media MSDVRMM_927466607_14848_131074.tmp Tue Jan 31 14:19:41 2006 10718 DENY_NONE 0x3019f RDWR EXCLUSIVE+BATCH /c/media MSDVRMM_927466607_14848_131074 Tue Jan 31 14:19:41 2006 10718 DENY_NONE 0x20196 WRONLY NONE /c/media Manual Recording__31_01_2006_13_26_07.dvr-ms Tue Jan 31 14:19:41 2006 10718 DENY_NONE 0x20089 RDONLY NONE /c/media Manual Recording__31_01_2006_13_26_07.dvr-ms Tue Jan 31 14:19:41 2006 And here is the smbstats for 3.0.11 for compare: Samba version 3.0.11 PID Username Group Machine ------------------------------------------------------------------- Service pid machine Connected at ------------------------------------------------------- media 8246 192.168.7.162 Tue Jan 31 12:02:03 2006 media 8246 192.168.7.162 Tue Jan 31 12:02:05 2006 Locked files: Pid DenyMode Access R/W Oplock Name -------------------------------------------------------------- 8246 DENY_NONE 0x30089 RDONLY LEVEL_II /c/media/MSDVRMM_927466607_131074_14848.tmp Tue Jan 31 12:02:05 2006 8246 DENY_WRITE 0x3019f RDWR LEVEL_II /c/media/MSDVRMM_927466607_131074_14848.tmp Tue Jan 31 12:02:05 2006 8246 DENY_NONE 0x20089 RDONLY NONE /c/media/Manual Recording__31_01_2006_11_08_11.dvr-ms Tue Jan 31 12:02:05 2006 8246 DENY_NONE 0x20196 WRONLY NONE /c/media/Manual Recording__31_01_2006_11_08_11.dvr-ms Tue Jan 31 12:02:05 2006 8246 DENY_NONE 0x3019f RDWR EXCLUSIVE+BATCH /c/media/MSDVRMM_927466607_131074_14848 Tue Jan 31 12:02:05 2006
Thanks for the quick response. The second entry in the share mode table with 3.0.21b is probably not valid - it's a placeholder being printed by mistake. I really need the ethereal log and smbd debug level 10 to be sure though, thanks. Jeremy.
I did one more test and upload the log.smbd-3021b and ethereal trace (mce-3021b). In this test, the first try to record somehow was rejected, and the second time try to record was started and play just freezed in MCE 2005 PC.
Created attachment 1715 [details] log.smbd for 3.0.21b test with MCE 2005 (winrar used)
I can not upload ethereal trace file, it is 9M after compresed. Pleaes tell me how to send it to you.
Oh, it is 25M instead of 9M.
Can you put these files somewhere on the web I can fetch them from ? Jeremy.
I'm looking at your smbd log at the moment, and I don't see any place it freezes yet. What does the client do when it freezes ? Can you still use a cmd.exe process to go into the Samba share and do a directory listing ? I need to understand more about the problem (also the network trace would really help :-). Jeremy.
What kind of file system is mounted on /c/media... ? Just wondering ? Jeremy
The /c is mount on EXT3 file system in the Linux 2.4.20. OK. I upload both the ethereal trace and smbd log in ftp2.infrant.com. user: infrant_support pass: starwars
By the way, the 192.168.7.239 is the Samba Server.
I still can use File explorer in MCE 2005 to browse the media share when MCE 2005 play freeze.
Ok, I've analysed your capture trace. Very interesting. It doesn't look like a Samba bug. Have you ever tried to do the same test against a remote Windows 2000 or 2003 server ? What I'm seeing in the trace is that writes completely dominate reads. ie. once you tell the mce to write the media file it just does nothing but streaming writes of 64k until the entrire file is completed. This is very efficient and almost certainly what you want (the incoming data from TV is very time critical and should take precedence over reads on being written onto disk). I'm willing to bet that against a Win2k or W2k3 server it would behave the same way. Since 3.0.11 we've put a lot more work into making us look much more like a wk2 server, and I'm guessing that one of the initial protocol exchange parameters (max write size etc.) makes this difference. We're now identical to W2K. I don't actually think this is a bug as we're probably behaving the same way as Windows does here, although if you could make an ethereal trace from 3.0.11 available I'd be able to check. Jeremy.
I upload the mce-3011 and mce-winxp to ftp2.infrant.com. Both of them have no problem for MCE 2005 play when recording. I think the 3.0.21b just return something ??? when MCE try to open the file to read during recording. It seems the MCE 2005 try to open same file twice, one is for recording (write) another is for playing (read).
FYI, change oplocks to 0 in Samba 3.0.21b does not resolve this problem.
Thanks, I'll take another look. I didn't see the open failing though. I'll look again. I appreciate your help on this. If it works against Windows then I guess we're doing something wrong..... although I need to understand what. Jeremy.
Ok, I think I've now spotted the error. If it's what I think it is, it's in delete on close semantics and is *incredibly* subtle :-). We didn't correctly implement delete on close semantics in 3.0.11 so that's why it works there. More debugging work to do.... Jeremy.
Yes, there are 2 system temp/hidden files created as "delete on close" when MCE 2005 start recording. So do you mean the MCE 2005 try to open them (for playing) while Samba 3.0.21b try to delete on close? And I can help on your debugging on this problem.
Created attachment 1716 [details] Patch Please apply this patch to 3.0.21b and retry. I think this will fix the bug. Thanks a *lot* for your help on this one - it was *really* nasty to track down :-). Not a show-stopper, so we won't be doing a 3.0.21c though. Jeremy.
I try the patch, it works pretty good with MCE 2005. I will do more test. Thanks a lot.
One problem comes out is the MSDVRMM_* files are not deleted after close recordings.
Can you get me another ethereal trace (and level 10 debug log) with the new code in place please ? The .tmp files should be being deleted on close (they are in the test code I wrote), so more info on fixing this would be helpful. Jeremy.
Each MCE recording makes 2 system temp file, one is MSDVRMM_*, another is MSDVRMM_*.tmp. Both of them shall be deleted after stop recording, which is the way mce-winxp do. Without the patch, 3.0.21b will delete both of them correctly.
Yes I understand that, but I need to see the logs to see why this isn't being done (the trace would help also). If you can make them available at the same ftp site that would help. Jeremy.
OK. I upload the logsmbd-3021b-p1 and ethereal trace mce-3021b-p1 to ftp2.infrant.com.
Ok I see what the problem is. The file with delete-on-close set is held open by the client at the time the client disconnects. We treat disconnectin differently than ordinary close as we're always root at disconnect time, and so can't just arbitrarily delete a file marked delete on close (what if the user who did that shouldn't have rights to delete ?). This is now the same issue as bug #3347 and needs to be fixed in the same way. Jeremy.
Is there a fix for #3347 now or will be a fix in the future? I see there is a special patch for #3347. Can I just use it?
That patch would work for you but would make generic Samba insecure. I'm working on a more correct fix but this will only be for 3.0.22. Jeremy.
I prefer to waiting for 3.0.22. Do you know when it will come out?
No date yet - probably 4 - 6 weeks, that's our usual schedule. Jeremy.
fixes in 3.0.23pre1