Installed, reinstalled, calibrated, I reset and the lights continue to flash at the same time. What can it be? Prints and once they start flashing, I have to reboot to be able to print again.
I changed thermal transfer to direct transfer. Now work perfectly!
Related
In ios, When we lock the screen the device goes into sleep mode and stops the download process and disrupts it. I used the react-native-keep-awake dependency but locks the screen anyway and is not a permanent solution. Is there any solution for this?
Check out https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/updating_your_app_with_background_app_refresh.
However, in the end you only have a short period of time to download data.
Issue description
AVSampleBufferDisplayLayer seems to hang on iOS 12.3.1 (>= iOS 12.2 is also affected) after
reboot. It looks that after 5 minutes everything works fine again.
The issue is not reproducible on iOS 11.
In our production code we don't use AVAssetReader, so please ignore any issues
with it, if minor.
I can make application hang on AVSampleBufferDisplayLayer init, enqueue and
requestMediaDataWhenReadyOnQueue.
Please advise how we should implement AVSampleBufferDisplayLayer correctly
(examples are welcome). Especially when we have to maintain and exchange
many display layers at once.
How to reproduce the issue:
Clone repo: https://github.com/mackode/AVSampleBufferDisplayLayer_Hanging
Download:
Tears of Steel segment
Put tearsofsteel_4k.mov_1918x852_2000.mp4 in Resources/ directory
Open AVSampleBufferDisplayLayer_BlackScreen.xcodeproj
Take iOS 12.3.1 device and reboot it
Start debugging AVSampleBufferDisplayLayer_BlackScreen
The video should start playing, then move a slider (seek) one or a few more times
Sample code is available here:
https://github.com/mackode/AVSampleBufferDisplayLayer_Hanging
Observed result:
Video hangs usually on AVSampleBufferDisplayLayer methods
Expected result:
Video seeks and continues to play
Can someone help me with solving this mistery?
I just met one of the weirdest bug on iOS at my lab.
One of our device (iPod Touch 5th gen, iOS 8.4.1) kept showing a wrong time, despite that the Location Service is on and the Set Automatically in Date & Time is on. The time on that device was always 5 mins late than the correct time.
That seems not to be a big deal but a bit annoying. However, one of our apps for clinic trails is time-sensitive: it always double checks whether the device has the correct time with our server; if the time is wrong, it won't be able to launch at all.
I checked online. It seems this bug has existed for several years! Every time after a system update, some devices will suffer from it. I tried all solutions I found, including restart the device, putting it in Airplane Mode, etc. However, none of them works for me.
Here is the solution I found:
I connected the device with a different network (in my case, from the Wifi at work to the Personal Hotspot on my iPhone), then restart the Set Automatically in Date & Time. BOOM, the time finally got back to accurate EST! After that, even if I reconnected the device back the the Wifi in the lab, the bug doesn't appear anymore and the time stays correct.
No idea what caused this problem, but it is definitely a bug in iOS.
I wrote a tweak called Dual Time, it displays second clock on the lock screen.
Everything works fine, but on one phone (iPhone 4) after uninstalling tweak something goes wrong and the phone goes into infinity respring loop. After hard reset, phone booted, but the Cydia icon disappeared and some applications could not be open. The owner of the phone had to burn the battery down to zero, and after that he was able to put his phone in DFU and restore firmware. On my 3GS I were unable to reproduce the bug, after re-installation and uninstallation tweak on the same iPhone 4 bug also wasn't appeared. Is anybody know why is that happened? Is something wrong with my tweak?
Tweek is located at http://appstudio.org/apt
I have also faced this problem and i have solved it using these steps:
put your device in recovery (not dfu) and wait for a while. After that press both the power and home button until the phone is turned off then release the power button and wait for a few seconds.
you must make build custom ipsw signed with your saved shsh (you can search for that on google) then the program will ask you to put your device into the pwned dfu.
run tiny umbrella and start server to avoid the problem (3194 ..etc
now run itunes and recover your iphone with the signed ipsw (not the original ipsw )
We built a game (that's a couple of weeks away from being submitted to Apple) and all this time we've been play testing / debugging on GSM phones (AT&T). One of use got a new iPhone 4 on Verizon. When he's on the 3G network, the game will launch to menu but if the use pushes "Play" nothing happens. However, if he joins a wi-fi network then pushes Play the game starts normally.
Has anyone encountered anything like this? We're fairly certain it's a software issue but have been searching the Internet for any info on what exactly the issue is.
We found out the problem! We changed ports. CDMA (Verizon) doesn't like port 4444, so we changed to another (random) one of 32545 and success! Thanks to everyone and remember kids, CDMA doesn't work on port 4444.
You need to figure out what specifically in your app is causing the game to fail to start. If you are not getting anything logged then there is presumably an error that is not being handled.
Given starting a game requires geolocation, my guess is that on the Verizon phone getting an accurate location fix is taking longer than your app expects and it is silently timing out, or that it is initially returning a location of 0.00000000, 0.00000000 and your app isn't liking that. When on Wifi, location services may be providing an instant initial estimate of location based on the known location of the Wifi network, which would then avoid the issue.
One way to test this would be to hardcode the location or seed an initial location into the app on launch, and see if this fixes the issue.