All of lore.kernel.org
 help / color / mirror / Atom feed
* Need help with bug in ftp-client executable from bluez-5.24 package
@ 2015-12-02  8:37 Konrad Antoniuk
  2015-12-02 10:57 ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 7+ messages in thread
From: Konrad Antoniuk @ 2015-12-02  8:37 UTC (permalink / raw)
  To: linux-bluetooth

Hi,

I’m looking to resolve an issue with one of the programs from the bluez package. I’m using the ftp-client python executable from the test folder and having trouble with transferring larger files. I’m running the program on the Intel Edison which runs Embedded Linux - Yocto. Initially the program worked for smaller files, 6.3 kB in size, but when I began experimenting with data files only double the size I began to run into trouble. Whenever the dbus signaled and called the callback method properties_changed, I initially received an error that the global variable value was left uninitialized. I solved that problem by adding the line value = properties[“Transferred”] at line 98 in the program, just before the speed calculation. This removed any reported errors received but the larger files still don’t transfer successfully. It seems whenever the signal’s callback function completes, the transfer doesn’t continue. I’ve attempted to call the Resume method from the Trans
 fer Interface but I must be doing something wrong because I’m fairly new to Python and debugging a program that uses dbus. 

To make it clear, the ftp-client executable from the test folder in the blues package works whenever the file transfer is completed before the Bus signals back. I’ve fixed an uninitialized variable bug but I still can’t get larger files to successfully transfer. I appreciate any guidance in correcting the source code and fixing this bug.

Thanks,

Konrad  

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Need help with bug in ftp-client executable from bluez-5.24 package
  2015-12-02  8:37 Need help with bug in ftp-client executable from bluez-5.24 package Konrad Antoniuk
@ 2015-12-02 10:57 ` Luiz Augusto von Dentz
  2015-12-02 13:11   ` Konrad Antoniuk
  0 siblings, 1 reply; 7+ messages in thread
From: Luiz Augusto von Dentz @ 2015-12-02 10:57 UTC (permalink / raw)
  To: Konrad Antoniuk; +Cc: linux-bluetooth

Hi Konrad,

On Wed, Dec 2, 2015 at 10:37 AM, Konrad Antoniuk <konrad18622@gmail.com> wrote:
> Hi,
>
> I’m looking to resolve an issue with one of the programs from the bluez package. I’m using the ftp-client python executable from the test folder and having trouble with transferring larger files. I’m running the program on the Intel Edison which runs Embedded Linux - Yocto. Initially the program worked for smaller files, 6.3 kB in size, but when I began experimenting with data files only double the size I began to run into trouble. Whenever the dbus signaled and called the callback method properties_changed, I initially received an error that the global variable value was left uninitialized. I solved that problem by adding the line value = properties[“Transferred”] at line 98 in the program, just before the speed calculation. This removed any reported errors received but the larger files still don’t transfer successfully. It seems whenever the signal’s callback function completes, the transfer doesn’t continue. I’ve attempted to call the Resume method from the Tra
 nsfer Interface but I must be doing something wrong because I’m fairly new to Python and debugging a program that uses dbus.
>
> To make it clear, the ftp-client executable from the test folder in the blues package works whenever the file transfer is completed before the Bus signals back. I’ve fixed an uninitialized variable bug but I still can’t get larger files to successfully transfer. I appreciate any guidance in correcting the source code and fixing this bug.

Have you tried with obexctl? ftp-client is actually deprecated so
chances are that it doesn't work properly anymore.


-- 
Luiz Augusto von Dentz

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Need help with bug in ftp-client executable from bluez-5.24 package
  2015-12-02 10:57 ` Luiz Augusto von Dentz
@ 2015-12-02 13:11   ` Konrad Antoniuk
  2015-12-02 14:34     ` Gowtham Anandha Babu
  0 siblings, 1 reply; 7+ messages in thread
From: Konrad Antoniuk @ 2015-12-02 13:11 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-bluetooth

Hello Luiz,

> On Dec 2, 2015, at 2:57 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> 
> Hi Konrad,
> 
> On Wed, Dec 2, 2015 at 10:37 AM, Konrad Antoniuk <konrad18622@gmail.com> wrote:
>> Hi,
>> 
>> I’m looking to resolve an issue with one of the programs from the bluez package. I’m using the ftp-client python executable from the test folder and having trouble with transferring larger files. I’m running the program on the Intel Edison which runs Embedded Linux - Yocto. Initially the program worked for smaller files, 6.3 kB in size, but when I began experimenting with data files only double the size I began to run into trouble. Whenever the dbus signaled and called the callback method properties_changed, I initially received an error that the global variable value was left uninitialized. I solved that problem by adding the line value = properties[“Transferred”] at line 98 in the program, just before the speed calculation. This removed any reported errors received but the larger files still don’t transfer successfully. It seems whenever the signal’s callback function completes, the transfer doesn’t continue. I’ve attempted to call the Resume method from the Tr
 ansfer Interface but I must be doing something wrong because I’m fairly new to Python and debugging a program that uses dbus.
>> 
>> To make it clear, the ftp-client executable from the test folder in the blues package works whenever the file transfer is completed before the Bus signals back. I’ve fixed an uninitialized variable bug but I still can’t get larger files to successfully transfer. I appreciate any guidance in correcting the source code and fixing this bug.
> 
> Have you tried with obexctl? ftp-client is actually deprecated so
> chances are that it doesn't work properly anymore.
> 
> 
> -- 
> Luiz Augusto von Dentz

Thanks for the quick response. I did get obexctl to transfer the larger file for me. However, for my application, I was using ftp-client through a system call within an SPP python program that interpreted my commands from a separate device. In addition, I was able to pass all of my options and arguments with a single shell command using this method. Will I be able to use obexctl the same way or is there another application that will allow me to do the same that isn’t deprecated?

Thanks,
Konrad    

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Need help with bug in ftp-client executable from bluez-5.24 package
  2015-12-02 13:11   ` Konrad Antoniuk
@ 2015-12-02 14:34     ` Gowtham Anandha Babu
  2015-12-02 22:44       ` Konrad Antoniuk
  0 siblings, 1 reply; 7+ messages in thread
From: Gowtham Anandha Babu @ 2015-12-02 14:34 UTC (permalink / raw)
  To: 'Konrad Antoniuk', 'Luiz Augusto von Dentz'
  Cc: linux-bluetooth

Hi Konrad,

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Konrad Antoniuk
> Sent: Wednesday, December 02, 2015 6:42 PM
> To: Luiz Augusto von Dentz
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: Need help with bug in ftp-client executable from bluez-5.24
> package
> 
> Hello Luiz,
> 
> > On Dec 2, 2015, at 2:57 AM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Konrad,
> >
> > On Wed, Dec 2, 2015 at 10:37 AM, Konrad Antoniuk
> <konrad18622@gmail.com> wrote:
> >> Hi,
> >>
> >> I’m looking to resolve an issue with one of the programs from the
> >> bluez package. I’m using the ftp-client python executable from the
> >> test folder and having trouble with transferring larger files. I’m
> >> running the program on the Intel Edison which runs Embedded Linux -
> >> Yocto. Initially the program worked for smaller files, 6.3 kB in
> >> size, but when I began experimenting with data files only double the
> >> size I began to run into trouble. Whenever the dbus signaled and
> >> called the callback method properties_changed, I initially received
> >> an error that the global variable value was left uninitialized. I
> >> solved that problem by adding the line value =
> >> properties[“Transferred”] at line 98 in the program, just before the
> >> speed calculation. This removed any reported errors received but the
> >> larger files still don’t transfer successfully. It seems whenever the
> >> signal’s callback function completes, the transfer doesn’t continue.
> >> I’ve attempted to call the Resume method from the Tr
>  ansfer Interface but I must be doing something wrong because I’m fairly
> new to Python and debugging a program that uses dbus.
> >>
> >> To make it clear, the ftp-client executable from the test folder in the blues
> package works whenever the file transfer is completed before the Bus
> signals back. I’ve fixed an uninitialized variable bug but I still can’t get larger
> files to successfully transfer. I appreciate any guidance in correcting the
> source code and fixing this bug.
> >
> > Have you tried with obexctl? ftp-client is actually deprecated so
> > chances are that it doesn't work properly anymore.
> >
> >
> > --
> > Luiz Augusto von Dentz
> 
> Thanks for the quick response. I did get obexctl to transfer the larger file for
> me. However, for my application, I was using ftp-client through a system call
> within an SPP python program that interpreted my commands from a
> separate device. In addition, I was able to pass all of my options and
> arguments with a single shell command using this method. Will I be able to
> use obexctl the same way or is there another application that will allow me to
> do the same that isn’t deprecated?
> 

Please try out the patch " [PATCH] test: Fix ftp-client not printing progress " which I have sent on ML.
Hope that solves your problem.

Regards,
Gowtham A

> Thanks,
> Konrad    --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Need help with bug in ftp-client executable from bluez-5.24 package
  2015-12-02 14:34     ` Gowtham Anandha Babu
@ 2015-12-02 22:44       ` Konrad Antoniuk
  2015-12-03  7:48         ` Gowtham Anandha Babu
  0 siblings, 1 reply; 7+ messages in thread
From: Konrad Antoniuk @ 2015-12-02 22:44 UTC (permalink / raw)
  To: Gowtham Anandha Babu; +Cc: Luiz Augusto von Dentz, linux-bluetooth

Hi Gowtham,

> On Dec 2, 2015, at 6:34 AM, Gowtham Anandha Babu <gowtham.ab@samsung.com> wrote:
> 
> Hi Konrad,
> 
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>> owner@vger.kernel.org] On Behalf Of Konrad Antoniuk
>> Sent: Wednesday, December 02, 2015 6:42 PM
>> To: Luiz Augusto von Dentz
>> Cc: linux-bluetooth@vger.kernel.org
>> Subject: Re: Need help with bug in ftp-client executable from bluez-5.24
>> package
>> 
>> Hello Luiz,
>> 
>>> On Dec 2, 2015, at 2:57 AM, Luiz Augusto von Dentz
>> <luiz.dentz@gmail.com> wrote:
>>> 
>>> Hi Konrad,
>>> 
>>> On Wed, Dec 2, 2015 at 10:37 AM, Konrad Antoniuk
>> <konrad18622@gmail.com> wrote:
>>>> Hi,
>>>> 
>>>> I’m looking to resolve an issue with one of the programs from the
>>>> bluez package. I’m using the ftp-client python executable from the
>>>> test folder and having trouble with transferring larger files. I’m
>>>> running the program on the Intel Edison which runs Embedded Linux -
>>>> Yocto. Initially the program worked for smaller files, 6.3 kB in
>>>> size, but when I began experimenting with data files only double the
>>>> size I began to run into trouble. Whenever the dbus signaled and
>>>> called the callback method properties_changed, I initially received
>>>> an error that the global variable value was left uninitialized. I
>>>> solved that problem by adding the line value =
>>>> properties[“Transferred”] at line 98 in the program, just before the
>>>> speed calculation. This removed any reported errors received but the
>>>> larger files still don’t transfer successfully. It seems whenever the
>>>> signal’s callback function completes, the transfer doesn’t continue.
>>>> I’ve attempted to call the Resume method from the Tr
>> ansfer Interface but I must be doing something wrong because I’m fairly
>> new to Python and debugging a program that uses dbus.
>>>> 
>>>> To make it clear, the ftp-client executable from the test folder in the blues
>> package works whenever the file transfer is completed before the Bus
>> signals back. I’ve fixed an uninitialized variable bug but I still can’t get larger
>> files to successfully transfer. I appreciate any guidance in correcting the
>> source code and fixing this bug.
>>> 
>>> Have you tried with obexctl? ftp-client is actually deprecated so
>>> chances are that it doesn't work properly anymore.
>>> 
>>> 
>>> --
>>> Luiz Augusto von Dentz
>> 
>> Thanks for the quick response. I did get obexctl to transfer the larger file for
>> me. However, for my application, I was using ftp-client through a system call
>> within an SPP python program that interpreted my commands from a
>> separate device. In addition, I was able to pass all of my options and
>> arguments with a single shell command using this method. Will I be able to
>> use obexctl the same way or is there another application that will allow me to
>> do the same that isn’t deprecated?
>> 
> 
> Please try out the patch " [PATCH] test: Fix ftp-client not printing progress " which I have sent on ML.
> Hope that solves your problem.
> 
> Regards,
> Gowtham A
> 
>> Thanks,
>> Konrad    --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org More majordomo
>> info at  http://vger.kernel.org/majordomo-info.html
> 

It works! Thanks for the help, it’s much appreciated. If it’s not too much trouble, can you or someone explain why additional changes to the preceding if statements made the difference in functionality? Running the original code, I’ve now noticed the additional exceptions printing a couple KeyError messages for the Status property. Why did these errors disappear when I made the undefined variable fix? 

Regards,
Konrad


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Need help with bug in ftp-client executable from bluez-5.24 package
  2015-12-02 22:44       ` Konrad Antoniuk
@ 2015-12-03  7:48         ` Gowtham Anandha Babu
  2015-12-05 13:08           ` Konrad Antoniuk
  0 siblings, 1 reply; 7+ messages in thread
From: Gowtham Anandha Babu @ 2015-12-03  7:48 UTC (permalink / raw)
  To: 'Konrad Antoniuk'
  Cc: 'Luiz Augusto von Dentz', linux-bluetooth

Hi Konrad,

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Konrad Antoniuk
> Sent: Thursday, December 03, 2015 4:14 AM
> To: Gowtham Anandha Babu
> Cc: Luiz Augusto von Dentz; linux-bluetooth@vger.kernel.org
> Subject: Re: Need help with bug in ftp-client executable from bluez-5.24
> package
> 
> Hi Gowtham,
> 
> > On Dec 2, 2015, at 6:34 AM, Gowtham Anandha Babu
> <gowtham.ab@samsung.com> wrote:
> >
> > Hi Konrad,
> >
> >> -----Original Message-----
> >> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> >> owner@vger.kernel.org] On Behalf Of Konrad Antoniuk
> >> Sent: Wednesday, December 02, 2015 6:42 PM
> >> To: Luiz Augusto von Dentz
> >> Cc: linux-bluetooth@vger.kernel.org
> >> Subject: Re: Need help with bug in ftp-client executable from
> >> bluez-5.24 package
> >>
> >> Hello Luiz,
> >>
> >>> On Dec 2, 2015, at 2:57 AM, Luiz Augusto von Dentz
> >> <luiz.dentz@gmail.com> wrote:
> >>>
> >>> Hi Konrad,
> >>>
> >>> On Wed, Dec 2, 2015 at 10:37 AM, Konrad Antoniuk
> >> <konrad18622@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> I’m looking to resolve an issue with one of the programs from the
> >>>> bluez package. I’m using the ftp-client python executable from the
> >>>> test folder and having trouble with transferring larger files. I’m
> >>>> running the program on the Intel Edison which runs Embedded Linux -
> >>>> Yocto. Initially the program worked for smaller files, 6.3 kB in
> >>>> size, but when I began experimenting with data files only double
> >>>> the size I began to run into trouble. Whenever the dbus signaled
> >>>> and called the callback method properties_changed, I initially
> >>>> received an error that the global variable value was left
> >>>> uninitialized. I solved that problem by adding the line value =
> >>>> properties[“Transferred”] at line 98 in the program, just before
> >>>> the speed calculation. This removed any reported errors received
> >>>> but the larger files still don’t transfer successfully. It seems
> >>>> whenever the signal’s callback function completes, the transfer doesn’t
> continue.
> >>>> I’ve attempted to call the Resume method from the Tr
> >> ansfer Interface but I must be doing something wrong because I’m
> >> fairly new to Python and debugging a program that uses dbus.
> >>>>
> >>>> To make it clear, the ftp-client executable from the test folder in
> >>>> the blues
> >> package works whenever the file transfer is completed before the Bus
> >> signals back. I’ve fixed an uninitialized variable bug but I still
> >> can’t get larger files to successfully transfer. I appreciate any
> >> guidance in correcting the source code and fixing this bug.
> >>>
> >>> Have you tried with obexctl? ftp-client is actually deprecated so
> >>> chances are that it doesn't work properly anymore.
> >>>
> >>>
> >>> --
> >>> Luiz Augusto von Dentz
> >>
> >> Thanks for the quick response. I did get obexctl to transfer the
> >> larger file for me. However, for my application, I was using
> >> ftp-client through a system call within an SPP python program that
> >> interpreted my commands from a separate device. In addition, I was
> >> able to pass all of my options and arguments with a single shell
> >> command using this method. Will I be able to use obexctl the same way
> >> or is there another application that will allow me to do the same that isn’t
> deprecated?
> >>
> >
> > Please try out the patch " [PATCH] test: Fix ftp-client not printing progress "
> which I have sent on ML.
> > Hope that solves your problem.
> >
> > Regards,
> > Gowtham A
> >
> >> Thanks,
> >> Konrad    --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-bluetooth" in the body of a message to
> >> majordomo@vger.kernel.org More majordomo info at
> >> http://vger.kernel.org/majordomo-info.html
> >
> 
> It works! Thanks for the help, it’s much appreciated. If it’s not too much
> trouble, can you or someone explain why additional changes to the
> preceding if statements made the difference in functionality? Running the
> original code, I’ve now noticed the additional exceptions printing a couple
> KeyError messages for the Status property. Why did these errors disappear
> when I made the undefined variable fix?
> 
> Regards,
> Konrad
> 

In ftp-client, properties_changed() method is triggered, whenever any g_dbus_emit_property_changed() signal is triggered from obexd/client/transfer.c.
In  the below links you can see obexd-client-transfer is triggering the "Status" or "Transferred" properties changed signal.
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/obexd/client/transfer.c#n212.
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/obexd/client/transfer.c#n801.

At one point we can expect either Status or Transferred signal. So we cannot have both properties changes signal to be emitted on one go.
That’s why there is an additional check for those properties existence in the patch mentioned.

Regards,
Gowtham A



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Need help with bug in ftp-client executable from bluez-5.24 package
  2015-12-03  7:48         ` Gowtham Anandha Babu
@ 2015-12-05 13:08           ` Konrad Antoniuk
  0 siblings, 0 replies; 7+ messages in thread
From: Konrad Antoniuk @ 2015-12-05 13:08 UTC (permalink / raw)
  To: Gowtham Anandha Babu; +Cc: Luiz Augusto von Dentz, linux-bluetooth

Hi Gotham, 

> On Dec 2, 2015, at 11:48 PM, Gowtham Anandha Babu <gowtham.ab@samsung.com> wrote:
> 
> Hi Konrad,
> 
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>> owner@vger.kernel.org] On Behalf Of Konrad Antoniuk
>> Sent: Thursday, December 03, 2015 4:14 AM
>> To: Gowtham Anandha Babu
>> Cc: Luiz Augusto von Dentz; linux-bluetooth@vger.kernel.org
>> Subject: Re: Need help with bug in ftp-client executable from bluez-5.24
>> package
>> 
>> Hi Gowtham,
>> 
>>> On Dec 2, 2015, at 6:34 AM, Gowtham Anandha Babu
>> <gowtham.ab@samsung.com> wrote:
>>> 
>>> Hi Konrad,
>>> 
>>>> -----Original Message-----
>>>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>>>> owner@vger.kernel.org] On Behalf Of Konrad Antoniuk
>>>> Sent: Wednesday, December 02, 2015 6:42 PM
>>>> To: Luiz Augusto von Dentz
>>>> Cc: linux-bluetooth@vger.kernel.org
>>>> Subject: Re: Need help with bug in ftp-client executable from
>>>> bluez-5.24 package
>>>> 
>>>> Hello Luiz,
>>>> 
>>>>> On Dec 2, 2015, at 2:57 AM, Luiz Augusto von Dentz
>>>> <luiz.dentz@gmail.com> wrote:
>>>>> 
>>>>> Hi Konrad,
>>>>> 
>>>>> On Wed, Dec 2, 2015 at 10:37 AM, Konrad Antoniuk
>>>> <konrad18622@gmail.com> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I’m looking to resolve an issue with one of the programs from the
>>>>>> bluez package. I’m using the ftp-client python executable from the
>>>>>> test folder and having trouble with transferring larger files. I’m
>>>>>> running the program on the Intel Edison which runs Embedded Linux -
>>>>>> Yocto. Initially the program worked for smaller files, 6.3 kB in
>>>>>> size, but when I began experimenting with data files only double
>>>>>> the size I began to run into trouble. Whenever the dbus signaled
>>>>>> and called the callback method properties_changed, I initially
>>>>>> received an error that the global variable value was left
>>>>>> uninitialized. I solved that problem by adding the line value =
>>>>>> properties[“Transferred”] at line 98 in the program, just before
>>>>>> the speed calculation. This removed any reported errors received
>>>>>> but the larger files still don’t transfer successfully. It seems
>>>>>> whenever the signal’s callback function completes, the transfer doesn’t
>> continue.
>>>>>> I’ve attempted to call the Resume method from the Tr
>>>> ansfer Interface but I must be doing something wrong because I’m
>>>> fairly new to Python and debugging a program that uses dbus.
>>>>>> 
>>>>>> To make it clear, the ftp-client executable from the test folder in
>>>>>> the blues
>>>> package works whenever the file transfer is completed before the Bus
>>>> signals back. I’ve fixed an uninitialized variable bug but I still
>>>> can’t get larger files to successfully transfer. I appreciate any
>>>> guidance in correcting the source code and fixing this bug.
>>>>> 
>>>>> Have you tried with obexctl? ftp-client is actually deprecated so
>>>>> chances are that it doesn't work properly anymore.
>>>>> 
>>>>> 
>>>>> --
>>>>> Luiz Augusto von Dentz
>>>> 
>>>> Thanks for the quick response. I did get obexctl to transfer the
>>>> larger file for me. However, for my application, I was using
>>>> ftp-client through a system call within an SPP python program that
>>>> interpreted my commands from a separate device. In addition, I was
>>>> able to pass all of my options and arguments with a single shell
>>>> command using this method. Will I be able to use obexctl the same way
>>>> or is there another application that will allow me to do the same that isn’t
>> deprecated?
>>>> 
>>> 
>>> Please try out the patch " [PATCH] test: Fix ftp-client not printing progress "
>> which I have sent on ML.
>>> Hope that solves your problem.
>>> 
>>> Regards,
>>> Gowtham A
>>> 
>>>> Thanks,
>>>> Konrad    --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-bluetooth" in the body of a message to
>>>> majordomo@vger.kernel.org More majordomo info at
>>>> http://vger.kernel.org/majordomo-info.html
>>> 
>> 
>> It works! Thanks for the help, it’s much appreciated. If it’s not too much
>> trouble, can you or someone explain why additional changes to the
>> preceding if statements made the difference in functionality? Running the
>> original code, I’ve now noticed the additional exceptions printing a couple
>> KeyError messages for the Status property. Why did these errors disappear
>> when I made the undefined variable fix?
>> 
>> Regards,
>> Konrad
>> 
> 
> In ftp-client, properties_changed() method is triggered, whenever any g_dbus_emit_property_changed() signal is triggered from obexd/client/transfer.c.
> In  the below links you can see obexd-client-transfer is triggering the "Status" or "Transferred" properties changed signal.
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/obexd/client/transfer.c#n212.
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/obexd/client/transfer.c#n801.
> 
> At one point we can expect either Status or Transferred signal. So we cannot have both properties changes signal to be emitted on one go.
> That’s why there is an additional check for those properties existence in the patch mentioned.
> 
> Regards,
> Gowtham A
> 
> 

Thank you for that concise explanation! It saved a lot of time and headache I would have gone through trying to learn and understand.

Regards,
Konrad


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-12-05 13:08 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-02  8:37 Need help with bug in ftp-client executable from bluez-5.24 package Konrad Antoniuk
2015-12-02 10:57 ` Luiz Augusto von Dentz
2015-12-02 13:11   ` Konrad Antoniuk
2015-12-02 14:34     ` Gowtham Anandha Babu
2015-12-02 22:44       ` Konrad Antoniuk
2015-12-03  7:48         ` Gowtham Anandha Babu
2015-12-05 13:08           ` Konrad Antoniuk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.