Opened 10 years ago

Closed 10 years ago

#6822 closed enhancement (fixed)

win32 patch to display drive letter instead of the devicePath when having multiple optical drives

Reported by: Jonathan Martens <jonathan@…> Owned by: Nigel
Priority: minor Milestone: 0.22
Component: Ports - Windows Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

When MythTV find multiple optical drives on a system it prsents the user a pop-up message to ask the user which device it should be controlling. In the current configuration the drivePath is assigned as label for the buttons, but in Windows this is not really suitable as it reads something like this:


.\{8213csad-3422dda-etc}

it would be easier if a user would just see the assigned drive letter just as in the Explorer. Attached patch accomplishes this.

Attachments (1)

win32-mythtv-libs-libmyth-mediamonitor_cpp.patch (750 bytes) - added by Jonathan Martens <jonathan@…> 10 years ago.

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by Jonathan Martens <jonathan@…>

comment:1 Changed 10 years ago by Nigel

I think it would be better to patch the code in the Windows subclass of the media monitor that is incorrectly filling in the volumeID from GetVolumeNameForVolumeMountPoint?(). Note that this code also does not yet actually monitor for media insertion, so my guess is that the current rubbish volume name is a manufacturer serial number from an empty drive at MediaMonitor? startup?

comment:2 in reply to:  1 Changed 10 years ago by Jonathan Martens <jonathan@…>

Thanks for your comments, they are welcome since I am pretty new to the source of MythTV and appreciate some guidance.

Replying to nigel:

I think it would be better to patch the code in the Windows subclass of the media monitor that is incorrectly filling in the volumeID from GetVolumeNameForVolumeMountPoint?().

OK I will see if I can provide a patch to change it there.

Replying to nigel:

Note that this code also does not yet actually monitor for media insertion, so my guess is that the current rubbish volume name is a manufacturer serial number from an empty drive at MediaMonitor? startup?

No, AFAICT it is not, it is the internal key that windows uses to access the CD player, but I will investigate some more.

comment:3 in reply to:  1 Changed 10 years ago by Jonathan Martens <jonathan@…>

Replying to nigel:

I think it would be better to patch the code in the Windows subclass of the media monitor that is incorrectly filling in the volumeID from GetVolumeNameForVolumeMountPoint?().

Is it really as the drivedetection algorithm seems to spit out the proper labels in the MythFrontend logfile:

2009-08-08 17:50:26.328 Creating inactive MediaMonitor and static device list
2009-08-08 17:50:26.328 IgnoreDevices=
2009-08-08 17:50:26.328 Found CD Drive : E:\
2009-08-08 17:50:26.359 Found CD Drive : F:\
2009-08-08 17:50:26.359 Initial device list: E:\ (E:\), F:\ (F:\)
2009-08-08 17:50:26.359 Registering 'MythMusic Media Handler 1/2'
 as a media handler for MEDIATYPE_MIXED
2009-08-08 17:50:26.359 Registering 'MythMusic Media Handler 2/2'
 as a media handler for MEDIATYPE_MMUSIC, ext(mp3,mp2,ogg,flac,wma,wav,ac3oma,omg,atp,ra,dts,aac,m4a)
2009-08-08 17:50:26.359 MonitorRegisterExtensions(0x40, mp3,mp2,ogg,flac,wma,wav,ac3oma,omg,atp,ra,dts,aac,m4a)

comment:4 Changed 10 years ago by Nigel

(In [21262]) Until appropriate Windows subclasses are coded, use default object. Refs #6822

comment:5 Changed 10 years ago by Nigel

MSDN tells me that routine returns the volume GUID path. Which might be useful to store in m_KeyID to detect if a disc has been changed, but is generally not useful. I'm hoping that there is something in GetVolumeInformation() that is more user friendly.

comment:6 Changed 10 years ago by Nigel

Resolution: fixed
Status: newclosed

(In [21266]) Windows API call that gets a reasonable volume name (at least for the CDs I have tested it with). Closes #6822

Note: See TracTickets for help on using tickets.