check buffering events #952

Merged

akinwale merged 5 commits from buffer-events into master

2020-07-21 20:30:46 +02:00

akinwale commented

2020-07-01 15:52:53 +02:00

(Migrated from github.com)

No description provided.

kekkyojin commented

2020-07-03 21:44:50 +02:00

(Migrated from github.com)

This looks like code for tracking activity performed by users, although for improving performance. I will check it with FDroid documentation and see if it could make the app still available but with a flag indicating it tracks certain activity.

In case it is non-acceptable for them, I will have to remove it from the FDroid port.

kekkyojin commented

2020-07-03 23:51:24 +02:00

(Migrated from github.com)

Could you add a setting on Preferences so users could opt-in to send this reports? You could set it "on" as default for the Play Store release version.

If It is set "off" as default only for the FDroid port, then no AntiFeature would be applied, according to https://f-droid.org/en/docs/Anti-Features/#Tracking

Could you add a setting on Preferences so users could opt-in to send this reports? You could set it "on" as default for the Play Store release version. If It is set "off" as default only for the FDroid port, then no AntiFeature would be applied, according to https://f-droid.org/en/docs/Anti-Features/#Tracking

kauffj commented

2020-07-07 00:23:27 +02:00

(Migrated from github.com)

Adding a setting for data sharing is a good idea, though we should probably model it after what we do on LBRY desktop.

@kekkyojin maybe this is a feature you could explore adding directly? 😁

Adding a setting for data sharing is a good idea, though we should probably model it after what we do on LBRY desktop. @kekkyojin maybe this is a feature you could explore adding directly? :grin:

kekkyojin commented

2020-07-08 20:44:24 +02:00

(Migrated from github.com)

From reading the commit I get that if player is buffering and has already began to play, then it will launch a new AsyncTask. That task will be sending some data to a host.

a) couldn't that sending of data consume bandwidth that could be making the user experience worsen? I suggest to stack a few of those buffering state bits of data and send them together. A timer could also be used in case no more buffering events had happened and only 1 is what needs to be sent.

b) AsyncTask is already deprecated. BufferEventTask doesn't return anything and dorsn't need to communicate with the UI thread. What about a thread, instead?

Another idea is to create a background service which is started first time a buffering event happens. That background service would be stacking the bits of data and sending them in a batch after certain time elapses -from the reception of the last bit of data- or the service is stopped.

From reading the commit I get that if player is buffering and has already began to play, then it will launch a new AsyncTask. That task will be sending some data to a host. a) couldn't that sending of data consume bandwidth that could be making the user experience worsen? I suggest to stack a few of those buffering state bits of data and send them together. A timer could also be used in case no more buffering events had happened and only 1 is what needs to be sent. b) AsyncTask is already deprecated. BufferEventTask doesn't return anything and dorsn't need to communicate with the UI thread. What about a thread, instead? Another idea is to create a background service which is started first time a buffering event happens. That background service would be stacking the bits of data and sending them in a batch after certain time elapses -from the reception of the last bit of data- or the service is stopped.

akinwale commented

2020-07-21 20:28:25 +02:00

(Migrated from github.com)

From reading the commit I get that if player is buffering and has already began to play, then it will launch a new AsyncTask. That task will be sending some data to a host.

a) couldn't that sending of data consume bandwidth that could be making the user experience worsen? I suggest to stack a few of those buffering state bits of data and send them together. A timer could also be used in case no more buffering events had happened and only 1 is what needs to be sent.

The data being sent is very little, probably less than 200 bytes, so I don't expect the user experience to worsen.

b) AsyncTask is already deprecated. BufferEventTask doesn't return anything and dorsn't need to communicate with the UI thread. What about a thread, instead?

AsyncTask helps keep things organised, in order to maintain the existing structure with the previous tasks already built. In the future, we can look into migrating away from AsyncTask if it no longer works for newer versions of Android, but it's still functional at the moment.

> From reading the commit I get that if player is buffering and has already began to play, then it will launch a new AsyncTask. That task will be sending some data to a host. > > a) couldn't that sending of data consume bandwidth that could be making the user experience worsen? I suggest to stack a few of those buffering state bits of data and send them together. A timer could also be used in case no more buffering events had happened and only 1 is what needs to be sent. The data being sent is very little, probably less than 200 bytes, so I don't expect the user experience to worsen. > b) AsyncTask is already deprecated. BufferEventTask doesn't return anything and dorsn't need to communicate with the UI thread. What about a thread, instead? AsyncTask helps keep things organised, in order to maintain the existing structure with the previous tasks already built. In the future, we can look into migrating away from AsyncTask if it no longer works for newer versions of Android, but it's still functional at the moment.