Good day do you know if is possible to change the mirror propierty when some subscriptor switching between cameras
You would need to unpublish with session.unpublish(publisher) followed by publisher.destroy();, and then republish with the new publisher options, including the new camera device id and updated mirror option.
Related
We have around 300k items on dmi_queue_item
If I do right click and select "destroy queue item" I see the that row no longer appears if I query by r_object_id.
Would it mean that the file no longer will be processed by the CTS service ? Need to know if this would it be the way to clear up the queue for the rendition process (to convert to PDF) or what it would it be the best way to clear up the queue ?
Also for some items/rows I get this message when doing the right click "destroy" thing, what does it mean ? or how can I avoid it ? Not sure if maybe the item was processed and the row no longer exists or is something else.
dmi_queue_item table is used as queue for all sorts of events at Content Server.
Content Transformation Service is using it to read at least two types of events, afaik.
According to Content Transformation Services, Administration Guide, ver. 7.1, page 18 it reads dm_register_assets and performs the configured content actions for this specific objects.
I was using CTS for generating content renditions for some objects using dm_transcode_content event.
However, be carefull when cleaning up dmi_queue_item since there could be many different event types. It is up to system administrators to keep this queue clean by configuring system components to use events or not to stuff up events that are not supposed to be used.
As per cleaning the queue it is advised to use destroy API command, though you can even try to delete row using DELETE query. Of course try to do this in dev environment first.
You would need to look at 2 queues:
dm_autorender_win31 and dm_mediaserver. In order to delete them you would run a query:
delete dmi_queue_item objects where name = 'dm_mediaserver' or name = 'dm_autorender_win31'
I have to monitor properties.desired properties changes from SimulatedDevice app, if any change (in my case fwVersion change) in the properties.desired then immediately my SimulatedDevice should be notified and start download the firmware image.
Since I could not find a relevant sourcecode in C# to try it out pl suggest.
Assuming your SimulatedDevice is using the Microsoft.Azure.Devices.Client NuGet package to connect to your IoTHub, you can subscribe to the device twin updates. To subscribe, use the DeviceClient.SetDesiredPropertyUpdateCallbackAsync method.
You can find an official sample in this repository. The file where they subscribe to the twin updates is this one.
I successfully registered an Android device to EMM.
Then I did a factory reset and registered it again.
Now I have the same device listed twice in my Device Management.
First thing: Is this behaviour wanted? I think there should be a rule that checks the IMEI and replaces the old object with the newly registered one.
Second thing: How do I get rid of the old object?
What if a phone gets destroyed and I can't unregister it unit-side?
Thanks in advance for any reply.
Conrad
We cann't replace the old device object with the new one because it might cause issues in shared-device scenarios (mostly COPE devices) where several users have access to the same device. So current user of the device must be able to login to EMM without removing the other owners' data. However I think this behavior must be changed to detect the Active device instance / owner from the same device instances and show it instead of showing multiple instances of the same device.
You can not delete the device from the EMM server by removing the registration from the client side. Only way to remove it would be manually removing the database table entry in the "devices" table of EMM database.
I had this problem, and found a (complicated) way to remove these zombie devices.
First of all stop your EMM server with a command like :
# /opt/wso2emm-1.1.0/bin/wso2server.sh stop
Then backup your databases:
# tar -zcvf /root/emm_db_backup.tar.gz /opt/wso2emm-1.1.0/repository/database/
Then start the H2 RDBMS:
java -cp /opt/wso2emm-1.1.0/repository/components/plugins/h2*.jar org.h2.tools.Server -web -webAllowOthers
Now, point your browser to http://YOUR_SERVER_IP:8082
Load the database with the JDBC URL:
jdbc:h2:/opt/wso2emm-1.1.0/repository/database/WSO2EMM_DB
(default User Name and Password are both wsocarbon)
You can list the devices with SELECT * FROM DEVICES
Delete the device by ID with: (change the 1 to whatever zombie device you want to get rid of)
DELETE FROM DEVICES
WHERE ID=1;
You're done! (well, after you stop H2 and start your server again)
I accidentally delivered the change set which include some additional config files having local system specific configuration in RTC. Is there any way to discard those changes once delivered? I mean the changes should not be come as incoming changes to other team members.
Please provide any pointer if you have.
Is there any way to discard those changes once delivered?
Not exactly: once delivered, that change set will come to the other team members as incoming.
There are two solutions:
revert the stream configuration to a state previous to your deliver. That is easy only if you are delivering baselines in addition of change sets, because you can then open the stream, and in the "component" section click on "Replace with", and replace the delivered baseline with the previous one.
But... if you never delivered baselines (and delivered only change sets), this isn't easy at all.
You can try and follow "Is there a way to create a RTC snapshot or baseline based on a past date?", but that is quite tedious.
Plus, if your colleagues already accepted your change set and started delivering change sets of their own, this solution isn't recommended at all.
Or, much simpler, you create a new changeset which will cancel the one you just deliver.
Right-click on your component, and select show > history, then right click on the latest change set you incorrectly delivered, and select revert.
That will create a patch.
Right-click on that patch, and select "apply to your workspace": that will create a change set which is the negative image of the one already delivered.
Deliver that new change set.
That means your colleagues will have to accept both change sets: the incorrect one, and the new one which cancels it.
This thread introduces a variation of the first alternative:
you can really remove the change set from the stream you delivered it to.
You can do this by:
discarding the change set from your local workspace
and then replacing the content of the stream with the content of your workspace for the particular component that's affected.
This is a more risky solution, because it really replaces the content of the stream with whatever you have in your workspace... it will remove anything in the stream that you don't have in your workspace. To do this:
a. Accept any incoming changes from the stream you are working with (to prevent losing anyone else's work).
b. Right click on the owning component in the Pending Changes view and select Show->History. The change set will appear in the History view.
c. Right click on the change set and choose Discard... This will discard the change set from your workspace.
So your workspace should now have all change from the stream except the one you want to remove. You can verify this by checking that your bad change set is the only thing you see Incoming.
d. Right click on the component and choose "Replace in [your stream name]..."
I want to be able to programmatically add Database(s) to the Replication and Sync tab in the Notes Client and then run the background replicator on the Notes Client.
Appreciate any ideas, I have scoured the web, to no end.
Adding the database to the replicator tab can be simply done with the replicate- method of the notesdatabase- class or via NotesUiWorkspace- methods. For the second suggestion you can find an example here.
Unfortunately you can not start background replication with LotusScript, you have to wait for it to occur.