Tracing Codepaths?

[Matthew]

I'm trying to trace the codepath that ends up executing ripDiskWrapper.sh . I'm looking for where the target rip format that's stored in the DB by the Adminsite "Installation Settings" form is (or, since it's buggy, isn't) is retrieved from the DB and passed to the ripDiskWrapper.sh commandline in Disk_Drive_Functions/RipTask.cpp .

I'd love some insight from someone who knows that code, but I'd settle right now for some simple tool to trace codepaths in LMCE as a whole. I don't want to have to use gdb unless I must, because I don't want to spend the time building all of LMCE (or even lots of its modules) with gdb symbols. I'd rather use some lexical code analyzer. And, if possible, keep my programming tools limited to grep, find, vi and make. Any suggestions?

[hari]

from the Powerfile_C200.cpp:526
                pMessage ? pMessage->m_dwPK_Device_From : 0,sFormat.empty() ? "ogg" : sFormat,sFilename,sDirectory,sTracks,true,this);

so m_sFormat in the RipJob object should get set up properly if the format string is passed when sending CMD_Rip_Disk. Disk_Drive should behave the same from what I've seen in the code.

Maybe you want to verify it rips other formats when you hand craft the message?

The RipFormat itself gets stored as device data in the Media Plugin device. Maybe that helps.

best regards,
Hari

[Matthew]

from the Powerfile_C200.cpp:526
                pMessage ? pMessage->m_dwPK_Device_From : 0,sFormat.empty() ? "ogg" : sFormat,sFilename,sDirectory,sTracks,true,this);

so m_sFormat in the RipJob object should get set up properly if the format string is passed when sending CMD_Rip_Disk. Disk_Drive should behave the same from what I've seen in the code.

Maybe you want to verify it rips other formats when you hand craft the message?

The RipFormat itself gets stored as device data in the Media Plugin device. Maybe that helps.

Well, I found that step, and it sets the format to ogg when the format is empty, which I believe is the actual bug (sending an empty sFormat). But I'm trying to find what calls that CMD_Rip_Disk(), which sends it an empty sFormat.

PowerfileRip_Task::RipCD() calls CMD_Rip_Disk() in Powerfile_C200.cpp line 876:

Code: [Select]

m_pDDF->CMD_Rip_Disk(m_iPK_Users, m_sFormat, sPath, sTracks, pRow_Disc->PK_Disc_get(), m_iDrive_Number, sCMD_Result, NULL);
m_pDDF is a (Disk_Drive_Functions *) according to Powerfile_C200.h :

Code: [Select]

        class Powerfile_Task : public Task
        {
                public:
(...)
                        Disk_Drive_Functions * m_pDDF;
(...)
        };

        class PowerfileRip_Task : public Powerfile_Task
        {
(no overridden m_pDDF)
        };

but I don't see where a Disk_Drive_Functions class has a member CMD_Rip_Disk() :

Code: [Select]

# grep CMD_Rip_Disk Disk_Drive_Functions/Disk_Drive_Functions.{cpp,h}
#

Which is why I'm looking for a way to trace the actual calling path through the code with a lexical analyzer or other similar code analyzer.

There are lots of other examples where the same function name is used in different classes for seemingly related methods, but with different method signatures (eg. omitting sFormat, or including it by passing a pointer to an object that contains it), which makes manually tracing the code frustrating. Not to mention the amount of repetitive code that should be bundled in an object rather than repeatedly invoking a 3rd or 4th degree submember, like all those LoggerWrapper calls. The code looks like a C programmer just wrapped C in C++ like a bunch of structs, which obfuscates the code. So a tool that can trace the callgraphs starting at some arbitrary point, and resolve pointers among different possible classes, will save a lot of hassle. Not just in this task, but in general.

[hari]

But I'm trying to find what calls that CMD_Rip_Disk(), which sends it an empty sFormat.

maybe you want to look at the DCERouter log? You know, it's all Data, Commands & Events

best regards,
Hari

[Matthew]

But I'm trying to find what calls that CMD_Rip_Disk(), which sends it an empty sFormat.

maybe you want to look at the DCERouter log? You know, it's all Data, Commands & Events

Good start for tracing dataflow through the DCE sockets. Thanks.


I click the "All/Rip" button in the jukebox's management Orbiter screen, and /var/log/pluto/DCERouter.log says:

Code: [Select]

08      01/21/08 18:13:40.647           Received Message from 20 (OnScreen Orbiter / Bedroom (Master)) to 20 (OnScreen Orbiter / Bedroom (Master)), type 1 id 741 Command:Goto Screen, retry none, parameters: <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 29(PK_MediaType): 0 <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 131(EK_Disc): -999 <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 159(PK_Screen): 19 <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 162(Caption): The default name to save this media under is shown below.  You may change it.  Then, touch 'Save Public' to make this media public, or, confirm that you are the current user and touch 'Save Private'.  Use / for subdirectories, like: dir/filename <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 236(Command): 20 33 1 720 17 <%=U%> 13 "<%=9%>"  <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 237(Advanced options): 1 <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 251(Interruption): 0 <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 252(Turn On): 0 <0x77804b90>
08      01/21/08 18:13:40.647             Parameter 253(Queue): 0 <0x77804b90>
08      01/21/08 18:13:40.648           Received Message from 20 (OnScreen Orbiter / Bedroom (Master)) to 10 (Media Plug-in / Bedroom (Master)), type 1 id 817 Command:Get Default Ripping Info, retry none, parameters: <0x7f814b90>
08      01/21/08 18:13:40.648             Parameter 13(Filename): Unknown disk <0x7f814b90>
08      01/21/08 18:13:40.648             Parameter 53(UseDefault): 1 <0x7f814b90>
08      01/21/08 18:13:40.649             Parameter 131(EK_Disc): -999 <0x7f814b90>
08      01/21/08 18:13:40.649             Parameter 219(Path):  <0x7f814b90>
08      01/21/08 18:13:40.649             Parameter 233(DriveID): 1 <0x7f814b90>
08      01/21/08 18:13:40.649             Parameter 234(Directory):  <0x7f814b90>
08      01/21/08 18:13:40.649             Parameter 235(Storage Device Name): CORE (#1) 7126MB <0x7f814b90>

I get prompted to specify the storage destintion for the rip, click the Orbiter "Save to Public" button, and the log says:

Code: [Select]

08      01/21/08 18:14:06.135           Received Message from 20 (OnScreen Orbiter / Bedroom (Master)) to 33 (VAIO DVD Changer / Bedroom (Master)), type 1 id 720 Command:Bulk Rip, retry none, parameters: <0x77804b90>
08      01/21/08 18:14:06.135             Parameter 13(Filename): /home/public/data/___audio___or___video___/ <0x77804b90>
08      01/21/08 18:14:06.135             Parameter 17(PK_Users): 1 <0x77804b90>
05      01/21/08 18:14:06.135           The target device 33 (routed to 33) has not registered. <0xb6c46b90>

The rip never starts, which seems to immediately abort as per Mantis bug#3784.

The "Get Default Ripping Info" command isn't supposed to include rip format, so that's OK. What's missing in the log is the rip format parameters in the "Bulk Rip" command, as per Powerfile_C200.cpp lines 531-544:

Code: [Select]

        /** @brief COMMAND: #720 - Bulk Rip */
        /** Mass ripping */
                /** @param #13 Filename */
                        /** A path where to put the files.  By default it will be /home/[public | user_xxx]/data/[music|movies].

If this parameter starts with a "/" it is considered absolute.  Otherwise it is considered a sub-directory under the aforementioned default */
                /** @param #17 PK_Users */
                        /** 0 to rip as public, or the user id to rip as private */
                [b]/** @param #20 Format */
                        /** For cd's only, flac,mp3,wav,ogg */[/b]
                /** @param #157 Disks */
                        /** Comma delimited list of slot number. For all, use "*". */

void Powerfile_C200::CMD_Bulk_Rip(string sFilename,int iPK_Users,[b]string sFormat[/b],string sDisks,string &sCMD_Result,Message *pMessage)

So the DCE comand is missing params 20 (Format) and 157 (Disks: slot number list or "*"). I expect the Powerfile device logic converts expected but missing DCE parameters into empty strings passed as arguments to the specified commands. The Powerfile_C200::CMD_Bulk_Rip() logic makes an empty sDisks argument equivalent to "*", which is correct in this instance (though that could hide a bug). But an empty sFormat argument defaults to ogg, which is the problem. The bug is upstream, probably in the Onscreen Orbiter's code that sends the "Bulk Rip" command to the Powerfile_C200 device.

But inspecting the Orbiter code doesn't reveal where that message is sent from, to start the tracing back upstream to where the Format param 20 is lost.